ElabNET Technik Forum

Hallo zusammen,
habe ein paar Fragen.

Info: Die Adresse 8/3/3 ist ein Mal in Visu hinterlegt.
<info styling="FensterOffen">
<address transform="DPT:6.001">8/3/3</address>
</info>

• Welche Telegramme sind es, die als "undefined" gekennzeichnet werden?

• Wieso kommt die Daten z.B 8/3/3 erstes Mal von der PA 1.1.20 und zweites Mal von der PA 1.1.22?

• Wieso kommt die Daten z.B 8/3/3 "undefined" manchmal zwei Mal von der PA 1.1.22?

• Habe ich im System noch irgendwo einen Fehler?

MfG Juri

Hui da ist aber was durcheinander.

Welche Geräte sind denn in der ETS mit der PA 1.1.20 und 1.1.22 definiert? (Ich habe das auch mal von GA auf PA korrigiert)

Sind es Tunneladressen der TWS-Schnittstelle oder sind es andere Geräte, wenn andere Geräte, dann senden diese Geräte warum auch immer diese Telegramme an die GA.

Sind es Tunneladressen kannst Du im KNX-Schnittstellenverwaltung den Verursacher (Container) identifizieren (IP-Adresse).


ist eine der beiden PA der TWS selbst könnte eine Logik / Regel die Ursache sein, da dann der TWS selbst als Gerät im Monitor erscheint.

Wenn das beides Container-PA sind dann scheint mir da einer einen Readrequest auf die jeweilige GA zu senden und erhält dann vom anderen Container eine entsprechende Antwort mit dem Temperaturwert, so werden wohl diverse Temperaturen abgefragt. Bei der 8/3/3 scheint es ähnlich nur kommt die erste Antwort so spät, das es schon eine erneute Anfrage gegeben hat. und durch die Datenlaufzeiten gab es dann auch zwei Antworten.

Die wesentliche Frage ist also wer ist PA 1.1.20 und warum werden da solche Readrequests generiert, wenn es denn welche sind?

Dann noch eine Frage ist der Busmonitor auf einer Schnittstelle im Applikation Modus oder im Real-Busmonitormodus?

Bei ersterer Variante hätte ich da jetzt eigentlich nicht erwartet das man das Telegramm vom Readrequest überhaupt sieht. Die Telegrammtypen müsste man doch aber mit dem Einblenden der zusätzlichen Spalten im Monitor auseinanderhalten können oder (Frage ans Elabnet Team)?

@gbglace Kann Juri denn schon die neue Schnittstellenverwaltung nutzen. Die gibts doch erst mit IP2 viewtopic.php?f=8&t=2089

Hallo Michael,

wegen Deiner Anmerkung zur Frage von Göran:

gbglace hat geschrieben: ↑Fr Apr 24, 2020 11:32 amDann noch eine Frage ist der Busmonitor auf einer Schnittstelle im Applikation Modus oder im Real-Busmonitormodus?

Hinweis: Der Applikationsmodus und der Real-Busmonitor-Modus schließen sich gegenseitig aus. Sobald eine Schnittstelle im Applikationsmodus ist, steht "nur" noch der virtuelle Busmonitor zur Verfügung (das kommt durch den KNX Standard, es ist keine Limitation des TWS).

Ob eine Schnittstelle im Applikationsmodus ist oder nicht - sieht man auch aus der "alten" Schnittstellenverwaltung. Und daraus kann man dann schließen, ob im "virtuellen" oder im "Real-Busmonitor" Modus.

lg

Stefan

Alles i.O. DIe undefined sind read requests und das andere die Antworten darauf. 1.1.22 fragt und 1.1.20 antwortet.

Sind es Tunneladressen kannst Du im KNX-Schnittstellenverwaltung den Verursacher (Container) identifizieren (IP-Adresse).

Die Tunnel Adressen sieht man doch erst in der neuen Version.

@StefanW

Hallo Göran,

gbglace hat geschrieben: ↑Fr Apr 24, 2020 11:32 am Hui da ist aber was durcheinander.

Welche Geräte sind denn in der ETS mit der PA 1.1.20 und 1.1.22 definiert? (Ich habe das auch mal von GA auf PA korrigiert)

Sind es Tunneladressen der TWS-Schnittstelle oder sind es andere Geräte, wenn andere Geräte, dann senden diese Geräte warum auch immer diese Telegramme an die GA.

Die wesentliche Frage ist also wer ist PA 1.1.20 und warum werden da solche Readrequests generiert, wenn es denn welche sind?

1.1.20 ist TWS selber
1.1.22 ist eine weitere reservierte PA vom TWS für die Kommunikation

Wieso solche Read-Requests generiert werden kann ich leider nicht sagen und ich weiß nicht, ob es normal/in Ordnung ist.

gbglace hat geschrieben: ↑Fr Apr 24, 2020 11:32 am Dann noch eine Frage ist der Busmonitor auf einer Schnittstelle im Applikation Modus oder im Real-Busmonitormodus?

Applikationsmodus

[/quote]

gbglace hat geschrieben: ↑Fr Apr 24, 2020 11:32 am
MfG Juri

gbglace hat geschrieben: ↑Fr Apr 24, 2020 11:32 am Hui da ist aber was durcheinander.

Hallo Göran,

du hast recht. Bei mir laufen immer noch sehr viele Sachen schief.
Zum Beispiel: Habe immer noch das Problem, dass die Status-GA in Visu den falschen Wert anzeigt, obwohl das Licht schon seit mehreren Stunden aus ist und das betrifft nicht nur eine bestimmte, sondern unterschiedliche GAs.

zum Beispiel hier.

Das Licht im Büro wurde um 23:50:02 ausgeschaltet und in Visu blieb der Status auf "AN".
Habe schon alles ausprobiert aber ich finde keinen Fehler

Kann mir jemand da weiter helfen?

Beispiel 2: Comet Visu zeigt Status Licht Bad = AUS, obwohl AN ist.

Die Logik zeigt aber den richtigen Wert an. K-150 = Status Licht Bad(0/2/0) -> In CV falsch = AUS -> In Logik Editor richtig "AN"

Visu

<switch mapping="OnOff" styling="RedGreen">
<layout colspan="3"/>
<label>Bad</label>
<address transform="DPT:1.001" mode="write">1/2/0</address>
<address transform="DPT:1.001" mode="read">0/2/0</address>
</switch>

MfG Juri

OK, die Schnittstellen Verwaltung in neu siehst erst mit dem neuen Softwarestand. Ich bin da nicht so gut das auseinanderzusortieren. Ich hab halt schon die neue bei mir drauf.

So dann sind die ganzen Temperaturen wohl 1-wire Werte? Die 1.1.20 der TWS sendet sie und wer anders fragt das ab. Die Fensterkontakte scheinen dann auch am 1-W zu hängen?

Wenn Du in der CV nen Licht bedienst, hat der Schaltbefehl dann auch die 1.1.22? Wenn nicht dann ist es nicht die Visu die da rund ruft, sondern ein anderer, ggf noch ein Logik PluginContainer?


Mit der CV kenne ich mich nicht so aus um sagen zu können warum er eine Status GA nicht sauber entgegennimmt, ob da ggf an den Buttons was falsch konfiguriert ist.

Diese CometVisu Funktion und Konfiguration wie eigentlich von jedem genutzt, d.h. wenn es hier ein Problem geben würde hätte das bestimmt schon jemand gemeldet.

Ich vermute daher, dass es ein Konfig Problem am TWS ist mit dessen Schnittstellen / Tunneln für sich selbst (Busmonitor, Logiken) so wie den weiteren für z.B. die CometVisu. Da ist der 2400er halt etwas limitierter als der 2500 oder 2600er.