NEU! UPGRADE IP 10 verfügbar!
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3

Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074

Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117

NEU! Ausführliches Video Tutorial zur IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs

[Gelöst] [V1.6 - Hells Bells] TWS schreibt / überträgt keine Werte mehr

Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
Sensej
Reactions:
Beiträge: 901
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 111 Mal
Danksagung erhalten: 240 Mal

#31

Beitrag von Sensej »

Robert_Mini hat geschrieben: Di Feb 02, 2021 7:20 am Richtig! In dem Fall macht das L-Flag nur an der Rückmeldung des Aktors Sinn, nicht am TWS Objekt.
In der TWS Applikation ist das L-Flag (leider) default und muss (meist) abgewählt werden.

Lg
Robert
Hallo Robert, Hallo Göran @gbglace
hier sind die Bilder meiner Konfiguration von der GA 0/2/6 und 1/2/6.
Bei der GA 0/2/6 ist der L-Flag nur beim Aktor gesetzt.
Bei allen Status-Objekten für das Licht ist der L-Flag nur beim Aktor "Status" gesetzt, sonst nirgendwo.
Bei dem TWS-Objekt 429, der mit der GA 1/2/6 zusammen verknüpft, ist der L-Flag drin.

Wieso kriege ich zwei Antworten auf eine Lese-Anfrage der GA 0/2/6 ? :roll:

Soll ich L-Flag bei Licht-Schalt-Objekten in TWS entfernen und beim Aktor-Objekt "Schalten" setzen oder braucht man da gar keinen L-Flag?

Ich habe ein paar Logiken, die mir die Anzahl der geschalteten Lichtquellen in Abhängigkeit von Licht-Status-Objekten(z.B. K-156 -> 0/2/6) ausgeben.
Was soll ich da beachten, Licht-Status-Objekt oder Licht-Schalten-Objekte verwenden und welche Flags?



01.jpg
11.jpg
12.jpg
13.jpg

MfG Juri
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt

gbglace
Reactions:
Beiträge: 3605
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1266 Mal
Danksagung erhalten: 1673 Mal

#32

Beitrag von gbglace »

Sensej hat geschrieben: Di Feb 02, 2021 12:08 pm Soll ich L-Flag bei Licht-Schalt-Objekten in TWS entfernen und beim Aktor-Objekt "Schalten" setzen oder braucht man da gar keinen L-Flag?
Für KO / GA die einfach nur Befehlsverteiler sind also ein Taster der Licht AN/AUS vorgibt oder eben ein TWS-KO. würde ich an keinem KO ein L-Falg vorsehen. Was soll das bringen, das ergibt nur die Information, was hat dieses Gerät das letzte mal auf den Bus gesendet. Das ist meist irrelevant.
Interessant ist soweit nur wie sieht gerade der Aktor aus, hat der Sein Relais offen oder geschlossen. Also eine echte Staus-Information sollte mit einem L-Flag versehen sein.

Es gibt zwar ausnahmen. Im KNX-UF ist z.B. einer dabei wissen zu wollen wie der Sperrstatus des BJ-PM Mini Premium ist um das an einem Taster an einer LED abzubilden. Da nutzt man die Sperre-auslösende GA auch um sie als Statusinformation an den LED-Eingang des Tasters zu verbinden. da der PM kein Status-Objekt zu seiner Sperre hat. Dem LED-Objekt am Taster könnte man dann Alternativ ein L-Flag vergeben. Auch wenn dieses Objekt selbst nicht Herr der Sperre ist.

Sensej hat geschrieben: Di Feb 02, 2021 12:08 pm
Wieso kriege ich zwei Antworten auf eine Lese-Anfrage der GA 0/2/6 ? :roll:
Hatte heute Morgen nur das Handy.

In dem Buslog im Beitrag #28 von Dir, sind doch gar nicht zwei Antworten zu sehen!

Eine Leseanfrage ist auch ein Telegramm.
Und bei Dir sieht man das bei beiden GA sauber. Im ETS-Monitor direkt neben dem Zeitstempel einmal ZUM Bus und einmal VOM Bus. ZUM-Bus ist der Rundruf durch den Klick in der ETS. Da geht ein Telegramm auf den Bus. Hallo liebe Gemeinde ich suche zu der GA 0/2/6 den aktuellen Wert und direkt danach meldet sich der AKS mit der Antwort VOM Bus mit der passenden Antwort, weil er das L-Flag an Seinem KO hat.
Ebenso deutlich wird es wenn Du die zehnte Spalte in dem Busmonitor etwas breiter machst. in der jeweils ersten Zeile steht da halt GroupValueReadRequest und bei der anderen dann GruopValueReadResponse, da die Spalte zu schmal ist ist das jetzt immer abgeschnitten. Im TWS-Buslog siehst Du das in der letzten Spalte, da haben die Buchstaben in der Spalte APCI eine entsprechende Bedeutung.

Irgendwie muss der Klick Leseanforderung ja auf den Bus gehen. Die begriffe sind da ggf etwas verwirrend oder man ist von anderen Systemen wie einer SPS fehlgeleitet. Es gibt keine Funktion im KNX das ein Gerät von der Busseite her ein anderes KO gezielt ausliest. (Ausnahme ggf PA-spezifizierte Telegramme) Alles was irgendwie mit GA zu tun hat ist immer ein aktives pushen von Informationen auf den Bus im braodcast also erstmal ungefiltert an ALLE. Der Filter sitzt an den KO quasi bei den Ohren. Und je nach Telegrammtyp ist ein solches Telegramm dann entweder ein Auftrag/reine Aussage oder eine Frage oder eine Antwort auf eine Frage. Ob ein KO auf all das reagiert ergibt sich durch die GA Zuordnung und wie es dann auf die Telegrammtypen reagiert oder agiert ergibt sich aus den Flags.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

Ersteller
Sensej
Reactions:
Beiträge: 901
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 111 Mal
Danksagung erhalten: 240 Mal

#33

Beitrag von Sensej »

Hallo Chris, Hallo Stefan @StefanW

wie kriege ich raus, ob CV die Verbindung verliert?
Die Verbindung der CV muss doch immer bestehen bis die Anwendung beendet wird oder?

Ich vermute, das ist der Grund wieso die Telegramme verschluckt werden, Status-Objekte nicht aktualisiert werden usw.
Ich bin am Verzweifeln, ich kriege es einfach nicht raus. :angry-banghead:
Habe schon alles geprüft, alle Flags, alle GA usw., an diesen kann es nicht liegen, weil die gleichen Funktionen ein Mal richtig ausgeführt werden und ein anderes Mal nicht. Habe schon 1000 Mal getestet.

Beispiel: Schalte ich Licht in der Küche an, dann wird alles in CV aktualisiert und angezeigt. Schalte ich ein zweites Mal das Licht in der Küche und warte ca. Sekunden und schalte wieder aus, dann wird der Staus in CV nicht aktualisiert.

Alle Telegramme sind im TWS richtig angekommen nur in CV nicht. Alle MDT-Schalter funktionieren und zeigen den Status richtig an.

Habe noch fest gestellt, dass BUS-Monitor(ETS) ständig die Verbindung verliert, siehe Bild unten
0.jpg
1.jpg

Meine Vermutung die CV verliert auch ständig die Verbindung. Das ist die einzige Begründung wieso die Telegramme verschwinden oder gar nicht ankommen und wieso alles 1 Mal geht und 10 Sekunden später nicht.

Die CV-Anwendung und der KNX-Busmonitor(ETS) war bei diesem Test immer an.

Zeit: X
5.jpg

Zeit: X + 5 Sekunden
6.jpg
Zeit: X + 10 Sekunden
7.jpg

@StefanW : Hi Stefan, könnt ihr bitte bei mir auf dem Server prüfen, ob es nicht irgendwie mit diesem Problem zusammenhängt.
viewtopic.php?f=21&t=2646#p29912

Ich weiß jetzt nicht mehr was ich noch prüfen muss damit die CV richtig funktioniert :confusion-helpsos:


Hat noch jemand Vorschläge?


MfG Juri
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt

StefanW
Elaborated Networks
Reactions:
Beiträge: 9752
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4869 Mal
Danksagung erhalten: 7766 Mal
Kontaktdaten:

#34

Beitrag von StefanW »

Juri,

eine Bitte: Klingle mich nicht bei fast jedem Beitrag heraus in dem Du mich erwähnst.

Das wird mir einfach zuviel, ich kann mich nicht um jedes Detail und schon gar nicht zeitnah kümmern. Ich garantiere dass ich alles lese was es neues gibt. Dann wenn ich dazu Zeit habe. Wenn ich auf etwas nicht antworte, dann weil ich nichts zu sagen habe dazu.

Ich bitte inständig darum meinen Wunsch zu respektieren.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
Sensej
Reactions:
Beiträge: 901
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 111 Mal
Danksagung erhalten: 240 Mal

#35

Beitrag von Sensej »

jawohl Stefan,
wird gemacht.
Ich versuche dich wirklich nur in Notfällen anzuschreiben und nur wenn ich seit längerer Zeit selber nicht weiter komme. ;)


MfG Juri
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt

gbglace
Reactions:
Beiträge: 3605
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1266 Mal
Danksagung erhalten: 1673 Mal

#36

Beitrag von gbglace »

Wie schaut denn Dein sonstiges LAN aus?

Ist das Stabil? bei der ganzen Kommunikation geht ja auch alles irgendwie durchs LAN, wenn es da Lücken gibt, dann kommt das auch nicht bei der ETS und nicht in den Containern an.

Wenn das TWS-Buslog vollständig ist, kann es schonmal nicht an der KNX-Schnittstelle im TWS liegen. Dann bleibt auch wieder nur die LAN-Schnittstelle im TWS. oder eben ein instabiles LAN im allgemeinen. Ganz naive Vermutung es ist was in Deinem LAN schief.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1194
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 236 Mal
Danksagung erhalten: 857 Mal
Kontaktdaten:

#37

Beitrag von Chris M. »

Sensej hat geschrieben: Di Feb 02, 2021 5:46 pm wie kriege ich raus, ob CV die Verbindung verliert?
Die Verbindung der CV muss doch immer bestehen bis die Anwendung beendet wird oder?
Keine Ahnung. So ein Verhalten habe ich bei mir noch nie gesehen.

Nur um sicher zu gehen: im Portainer beim CometVisu-Container, was steht da unter "Start time"? Passt die zum Start des Containers oder eher zu einem (vermuteten) Verbindungsverlust?
Sensej hat geschrieben: Di Feb 02, 2021 5:46 pm Ich vermute, das ist der Grund wieso die Telegramme verschluckt werden, Status-Objekte nicht aktualisiert werden usw.
[...]
Meine Vermutung die CV verliert auch ständig die Verbindung. Das ist die einzige Begründung wieso die Telegramme verschwinden oder gar nicht ankommen und wieso alles 1 Mal geht und 10 Sekunden später nicht.
Klar, wenn was am Bus passiert und während dessen besteht keine Verbindung, dann bleibt's blind.
Sensej hat geschrieben: Di Feb 02, 2021 5:46 pm Habe noch fest gestellt, dass BUS-Monitor(ETS) ständig die Verbindung verliert, siehe Bild unten
Die CV ist darauf angewiesen, dass kontinuierlich eine Verbindung zum KNX IP Tunnel besteht. Daher denke ich, dass dieses Thema zuerst gelöst werden muss.
(Deswegen wollte ich mit der ETS testen lassen, da die vergleichbar auf den Bus zugreift und wir so die Schnittstelle testen konnten.)
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

Ersteller
Sensej
Reactions:
Beiträge: 901
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 111 Mal
Danksagung erhalten: 240 Mal

#38

Beitrag von Sensej »

gbglace hat geschrieben: Di Feb 02, 2021 7:47 pm Wie schaut denn Dein sonstiges LAN aus?

Ist das Stabil? bei der ganzen Kommunikation geht ja auch alles irgendwie durchs LAN, wenn es da Lücken gibt, dann kommt das auch nicht bei der ETS und nicht in den Containern an.

Wenn das TWS-Buslog vollständig ist, kann es schonmal nicht an der KNX-Schnittstelle im TWS liegen. Dann bleibt auch wieder nur die LAN-Schnittstelle im TWS. oder eben ein instabiles LAN im allgemeinen. Ganz naive Vermutung es ist was in Deinem LAN schief.

Hallo Göran,
LAN ist stabil.
Vorher ist alles gelaufen bevor TWS aufgehört hat KNX-Telegramme zu schicken.
viewtopic.php?f=21&t=2646#p29912

Danach Neustart des Servers und ein Problem nach dem anderen.


MfG Juri
Zuletzt geändert von Sensej am Mi Feb 03, 2021 12:12 am, insgesamt 1-mal geändert.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt

Ersteller
Sensej
Reactions:
Beiträge: 901
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 111 Mal
Danksagung erhalten: 240 Mal

#39

Beitrag von Sensej »

Chris M. hat geschrieben: Di Feb 02, 2021 11:38 pm
Die CV ist darauf angewiesen, dass kontinuierlich eine Verbindung zum KNX IP Tunnel besteht. Daher denke ich, dass dieses Thema zuerst gelöst werden muss.
(Deswegen wollte ich mit der ETS testen lassen, da die vergleichbar auf den Bus zugreift und wir so die Schnittstelle testen konnten.)

Hallo Chris,

ich bin einen Schritt weiter :violin:
Der Ansatzpunkt war: die Verbindung vom ETS-Busmonitor und CV zur KNX-Schnittstelle wurde immer wieder abgebrochen und wieder neu aufgebaut.
Sowas sollte nicht passieren aber die Verbindung wurde fast jede Minute unterbrochen, krass :shock:
Das kann nur an der KNX-Schnittstelle liegen, weil ich schon alle anderen Fehlerquellen ausgeschlossen habe.
Dann habe ich die KNX-Schnittstelle neu gestartet und nochmal mit dem ETS-Busmonitor getestet.

Ergebnis: In 30 Minuten keine einzige Unterbrechung -> endlich das erste positive Zeichen, dass ich mich in die richtige Richtung bewege

CV-Container habe ich auch neu gestartet. Die Ladezeit war viel kürzer als vorher.
Ich werde CV die nächsten Tage testen und berichten wie der Stand der Dinge ist.

Also bis jetzt hat mir das Ganze 4 Tage gekostet :cry:

MfG Juri
Zuletzt geändert von Sensej am Mi Feb 03, 2021 8:26 am, insgesamt 1-mal geändert.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt

Ersteller
Sensej
Reactions:
Beiträge: 901
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 111 Mal
Danksagung erhalten: 240 Mal

#40

Beitrag von Sensej »

Hallo zusammen,
ein kurzer Zwischenbericht.
CV läuft seit gestern ohne Probleme.
Die Telegrammen erreichen auch ihr Ziel, die Zugriffszeiten sind auch in Ordnung.

Die Ursache war die KNX-Schnittstelle, die sich aus irgendeinen Grund aufgehängt hat.

Kurze Frage: Wieso ist hier die PA 1.1.255 und nicht eine zwischen 21 und 28??

2021-02-03 11_24_06-Schnittstellen _ Timberwolf.jpg
MfG Juri
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt
Antworten

Zurück zu „KNX“