Je komplexer eine Entwicklung wird, desto mehr findet man die Lücken. Eine EIN/KNX Buskomponente muss in der Lage sein, Werte aus der IPS ggf. zu lesen.
Eigentlich ist das eine banale Basisfunktion: Eine EIB Bus-Komponente möchte einen Zustand abfragen, der durch IPS gehalten/gehostet wird.
Jede noch so simple zustandsführende Komponente eines EIB-Bus kann das, z.B. einen Rückmeldekanal für einen Schalterzustand zur Verfügung stellen. IPS scheint leider auf Leseanforderungen gar nicht zu reagieren. Es fehlt die Möglichkeit ein Flag zu setzen, das IPS mitteilt, dass die Variable einer Instanz bei Abgefrage durch IPS selbst gesendet werden muss. Ist dieses Flag gesetzt, so muss IPS den Variablenwert automatisch an den Bus bei einer Abfrage an die Gruppenadresse senden. Im Prinzip also eine Art „Schreiben“ / „Übertragen“ Flag, wie in der ETS oder anders gesprochen: IPS hostet die Variable.
IPS ist wirklich genial, aber mir fiel der Kinnladen runter :eek:, als ich merkte, dass so eine grundlegende Funktion fehlt. Habe ich etwas übersehen…?
Extrem wichtig wäre diese Funktion auch bei systemübergreifenden Topologien. Aus Netz A (z.B. EIB) soll der Zustand eines anderen Netzwerks B (z.B. LCN, Enocean, etc) gelesen werden. In diesem Fall wäre IPS eine Art Gateway.
P.S. Es ist ein Unterschied, ob ein Wert „bei Änderung“ auf den Bus gegeben wird oder ob dieser „abgefragt“ wird!
Immerhin hat ja bisher keiner wirklich sinnvoll geantwortet :rolleyes:
Eindeutig JA … du hast was grundlegendes Übersehen s.u.
Seit wann ist eine VISU ein GATEWAY???
Wenn ein „bei Änderung“ Telegramm auf dem BUS ist, LIESST die VISU mit, so sie will.
Bei einer aktiven Statusabfrage wird der STATUS einer Komponente oder einer VISU aktiv abgefragt.
Ein VISU, die z.B. mittels OPC oder LibNoDaVe oder sonstwie angebunden wird,
hat typscherweise keine eigenen TAGs sondern ließt und schreibt TAGs der
angeschlossenen Steuerungen.
Daher importiert man z.B. alle notw. bzw. KNX-TAGs in die VISU und kann
dann damit arbeiten.
Die VISU ist aber für die KNX-Komponenten unsichtbar und hat keine echte
eigene physikalische Adresse, die man von außen lesen und schreiben könnte.
Daher sind deine Gedanken ein Irrweg und kein „missing Feature“
Nun, IPS ist wohl deutlich mehr als nur eine VISU.
Was genau IPS ist hängt wohl eher vom Benutzer ab, von daher kann ich schon verstehen das der wunsch nach „vollständiger“ implementierung der EIB
möglichkeiten vorhanden ist.
Mein IPS ist z.B. Logik, Alarmsystem, Gateway EIB<->FS20, Ablaufsteuerung, Nachrichtenzentrale etc…
Allerdings verstehe ich auch das die Entwickler eben aufgrund der funktionsvielfalt von ips nicht alles sofort machen können
Wenn du speziell den KNX (den EIB) ansprichst, ist weder der oft verwendete
HOMESERVER (GIRA) noch der EibPC (Entertex) noch eine Eisbärvisu von aussen
über GAs ansprechbar. Auch beim KNX-OPC-SERVER ist das so.
Solche Geräte haben keine eigene (von Hand beeinflußbare) pysikalische Adresse.
Dem „restlichen“ BUS ist es piepegal, ob da „obendrüber“ ein SERVER oder eine
VISU ist. Daher ist es nicht der richtige Weg sich ein „Bespielen“ von TAGs von
aussen zu wünschen.
99,9% Prozent der User vermissen das nich, weil eine klare TOP-DOWN-STRUKTUR
wichtige ist als sich Abhängigkeiten überkreuz zu schaffen.
Wenn du diese Frage im KNX-FORUM stellen würdest, wäre die Anwort in
etwa die gleiche, wie ich sie gerade formuliert habe.
ich wollte hier nicht die Gemüter erhitzen oder jemand auf den Schlips treten. Allerdings muss ich widersprechen: Die Möglichkeit mit PHP Skripte zu schreiben, diese ereignisgesteuert auszulösen, Zustände zu lesen und Werte auf den EIB-Bus zu schreiben (Verarbeitung) sind klare Eigenschaften einer Automatisierungssoftware (1). Die Visualisierung gibt es noch nebenbei und ist das Sahnehäubchen auf der Basisfunktionalität. Mir ist klar, dass die Meisten vor lauter Sahne den Kuchen darunter nicht mehr sehen :D…
IPS hört den EIB-Bus ab. Ohne diese Eigenschaft können über die Instanzen keine Variablen aktualisiert werden. Diese Instanzen können wiederrum Werte auf den EIB schreiben. Die Kommunikation ist also bereits bidirektional (2).
IPS und der EIB interagieren. Somit kommt man zum Schluß, dass weder technische (2) noch philosophische Gründe (1) für diese Einschränkung sprechen. Vielmehr würde das Anwendungsfeld der IPS und letztendlich auch EIB durch die Möglichkeit komplexer Anwendungen enorm profitieren.
Waum? Die Anzahl der Logikgatter ist in einem Bus beschränkt und mit diesen lassen sich nicht alle gewünschten Funktionen abbilden (Die Welt besteht nicht nur aus UND und ODER ;), sie ist viiiieeeel komplexer).
Wir hatten dieses Thema ja schon des öfteren. EIB/KNX wird leider seit jeher etwas Stiefmütterlich von IPS behandelt. Die letzte größere Ergänzung waren der Konverter und das Hinzufügen weiterer Rückmeldeadressen. Das generelle Fehlen einer Möglichkeit, zur aktiven Abfrage / Lesen eines Status wurde schon mehrfach bemängelt.
Natürlich fehlt es nicht, wenn IPS IMMER mit läuft. Aber leider gibt es doch hin und wieder ein Restart oder ich muss den Service Stoppen um mit der ETS auf mein IP-Gateway zugreifen zu können. Hier vermisse ich durchaus auch immer wieder eine Funktion zum „Initialisieren“ oder ein Befehl zum aktiven auslesen der Werte.
Ich habe mir hier etwas unschön geholfen, indem ich zumindest meine Aktoren regelmässig ihren Status auf den Bus senden lasse, im Schnitt alle 5 Minuten. Leider bieten nicht alle Geräte eine solche Option und ich schicke im Prinzip unnötig Telegramme raus.
Da wir alle mehr oder weniger gelernt haben mit dem Fehlen dieser grundlegenden Funktion zu Leben oder uns Workarounds geschaffen haben ist dies sicher kein Prio A Problem… dennoch hoffe ich auch weiterhin inständig, dass es hier mittelfristig eine saubere Lösung seitens geben wird.
PS: IPS ist definitiv mehr als eine reine VISU und wir auch als ein Solches beworben. Die VISU ist für mich nur ein einfaches Interface zum eigentlich Herz der Sache… und natürlich ein gewaltiger WAF ;-))
in einem System welches Ereignisbasierend ist, also keine SPS die ständig
alles pollt, ist es z.B. in einem EibPC oder Homeservern völlig normal, das
sie alle Telegramme am Bus mithören oder durch Zustandabfragen das
eigene Abbild akualisieren. Typischerweise braucht so eine Einheit nach dem
Einschalten eine gewisse Zeit sich auf das System aufzusynchronisieren.
Das ist der große Unterschied zur SPS. Aber wir reden ja vom EIB und da
muß man z.B. nach dem Hochfahren der VISU oder des Homeserver oder
EibPCs einige Automatismen erst einmal mit einem DELAY(2-5 Minuten) sperren,
bis das Abbild halbwegs synchron zum Zustand aller verwendeten Gruppen-
adressen ist. Das heißt wir reden vom Mithören oder vom akiven Abfragen.
Ich habe zu Hause ein KNX/EIB-System mit etwa 40 Teilnehmern einem
EibPC. Der EibPC erhält per Variablenexport aus der ETS alle verwendeten
GAs, die dann im Code des EibPCs verwendet werden.
Der Sinn des EibPC ist u.a. mitzuhören, welche Fenster und Türen geöffnet
werden (nach dem Einschalten fragt er den STATUS aber auch einmalig ab).
Auch werden Temperaturen und Schaltzustände im EibPC-internen Variablen-
abbild mitgeführt, sodass zu jeder Zeit ein Zustandsimage des realen EIB-Netzes
exisitiert.
Für die „lieben“ KNX-Teilnehmer - egal ob Sensoren oder Aktoren ist der
EibPC wie auch jede andere Art von IP-Zugriff nicht sichtbar.
auch exisitieren in den Verbindungslisten der ETS keine separaten GAs,
die auf einen angeschlossene externe Befehlseinheit hinweisen könnte.
Die Teilnehmer wissen nix von EibPC/Visu. Daher ist es auch nicht möglich,
dass ein Sensor aktiv eine Variable IM EibPC beschreibt. Was allerdings
geht und auch genutzt wird ist eine Art DUMMY-Teilnehmer. Das ist
eine Art Datenspeicher, wenn eine Sensor beschreiben kann, wenn es
für einen Schalt- oder Meldefunktion keinen echten EIB-Teilnehmer gibt.
Aber auch hier schickt der Sensor die Meldung auf den BUS, ohne das
der Sensor überhaupt erfährt, ob der EibPC aktiv oder am Netz oder
ausgeschaltet ist. Es ist also kein Senden mit Rückmeldungs- oder
Statusabfrage.
Will also heißen, man kann jetzt schon über DUMMY-GAs Zusände in den
BUS senden, die nur für den angeschlossenen PC nützlich und verwendbar
sind. Ein echtes Auslesen eines Variablenwertes bzw. -zustandes aus
dem angeschlossenen PC - SERVER - VISU ist auf diesem Wege in der
Eib-Welt nicht üblich/möglich. Das geht nur mit STATUSABFRAGE und
ANTWORT. Dann schreibt der PC aktiv auf eine DUMMY-GA falls er auf
einer anderen DUMMY-GA eine ANFRAGE „mitgehört“ hat. So ist der Weg.
Lieber Frank,
ich verstehe sehr gut, wie diese Technik funktioniert. Ich bin selbst Informatiker. Hat Du Dich einmal gefragt, wieso ein KNX/IP Gateway eine EIB Adresse besitzt ? Hast Du dich weiterhin gefragt, weshalb dieser Gateway nur Punkt-zu-Punkt IP-Verbindungen zulässt?
Hier findest Du eine gute Einführung zum KNX-Stack http://www.weinzierl.de/download/references/KnxIp_Doc_E.pdf. Achte mal auf Seite 7. Dort findest du „…It handles all GroupValueRead and GroupValueWrite requests received from the transport layer…“. qed. Die benötigte Funktionalität ist also im EIBnet/IP Stack vorhanden.
Weiterhin hättest Du Dir das auch selbst ohne Kenntnis des Protokoll Stacks erschließen können, denn in der ETS kannst Du alle Protokollpakete tracen…und das geht nur, indem man diese Pakete via EIBnet/IP ebenfalls übermittelt bekommt. Das ist keine Zauberei. Das Gateway ist im EIB-Netz bekannt und über seine EIB Adresse adressierbar. Via IP-P2P Verbindung wird das Protokoll auf genau einen IP-Teilnehmer gemappt, im Klartext: Der IP-Teilnehmer wird wie genau ein EIB Teilnehmer behandelt.
Was also „üblich/möglich“ ist wäre damit geklärt.
Was ist in IPS zu tun? Recht wenig. Eigentlich muss man einer GA-Instanz in IPS lediglich ein Flag verpassen können, damit IPS weiß, dass es auf Leseanforderungen dieser GA reagieren soll und den Wert der verbunden Variablen automatisch sendet. Wie Michael Jackson sagte „this is it“.
geben wird.