[TIPP] [V 3.1] Inbetriebnahme Probleme und Fragen zu den ersten gehversuchen

[Zelkin]

Hallo TWS Forum

Ich habe diese Woche meinen TWS 3500 bekommen und habe noch so meine Probleme bei der Einrichtung, Ich hoffe ihr könnt mir dazu gute Tipps geben.

Zu meiner Konstellation:
2 Familienhaus mit KNX + IO Broker auf einem Zentralen Server
Über IOBroker verbinde Ich derzeit Zigbee / Sonos / KNX / MQTT / Plex / Shelly / ..... miteinander
Der IOBroker hat bisher meine Zentrale gebildet, da einige Funktionen von KNX intern nicht genügend Funktionen mitbrachten!
Nun Kämpfe Ich schon seit ner gefühlten Ewigkeit mit dem KNX Adapter, da meine Schnittstelle immer wieder aussteigt und mein Haus ca. 2Min. sozusagen eine Denkpause einlegt.

Mein neuer Lösungsansatz TWS 3500L [3.1] Insider:dance:

Das gerät ist gekommen und Ich bin begeistert .... läuft schonmal Grundsätzlich ganz gut das kleine Kästchen

Mein Vorhaben ist nun KNX aus dem IOBroker rauszunehmen und das Thema Komplett auf dme TWS zu behandeln ... die Daten tausche Ich dann über MQTT mit dem IOBroker aus

Nun sind mir bei der ersten Bedienung ein Paar Fragen aufgekommen, bei denen ihr mir hoffentlich sagen könnt ob Ich was Falsch mache oder ob das so gehört

- Von der 32GB SSD sind nur ca 18GB Frei ( + Anderes mit 2,5GB und Docker mit 392MB) reserviert sich das Grundsystem 10GB?

- Das Tunneling über den TWS ist Instabil, nach ca. 30 min. sagt IOBroker Verbindung steht, im TWS in der auflistung der Tunnel wird der IOB nicht mehr geführt und es kommen auch keine Telegramme mehr auf dem Bus an --> gibt es hier besondere Einstellungen welche Ich vornehmen muss, damit die Verbindung erhalten bleibt?

- Der Download der Datensicherung führt zu Fehler 404 Not Found (Insider Problem?)

- KNX Objekte werden erst angezeigt wenn Ich sie dementsprechend in der ETS zuweise
--> kann Ich in der ETS die Zuweisung der DPT irgendwie vereinfachen, oder muss Ich wirklich jeden universalpunkt sauber zuweisen
--> Wenn Ich eigentlich das Komplette KNX System zur Weiterverwendung auslesen möchte MUSS Ich in jede GA einen Datenpunkt setzen da die Daten über den Busmonitor zwar verfügbar sind, aber dort nicht weitergegeben werden können?
--> Flags: S Flag nur bei Datenpunkten bei denen Ich auch schreiben möchte (z.B. Schalten Steckdose) oder lasst ihr den immer stehen, weil er eigentlich nicht stört
--> Flag L: Bei Sensorwerten würde Ich den rausnehmen, da ja der Sensor ausgelesen werden sollte und nicht der TWS ..... kann Ich den Lesen bei Init trotzdem verwenden? oder eher nicht
--> Ist es möglich den K Wert von KNX Objekten irgendwie zu ändern? Damit die mehr Aussagekraft bekommen

MQTT:
--> Kann Ich irgendwie alle Werte Subscriben bzw. alle werte eines Gerätes und der TWS erstellt mir dann automatisch eine Art Baum daraus?
--> Kann Ich zumindest alle zur Verfügung stehenden Werte im TWS Irgendwo anzeigen lassen um das Subscriben zu vereinfachen?
--> Kann Ich bei einem neu Angelegten App Level Topic nachträglich das App Level Ändern, also die MQTT "Adresse" nachträglich ändern

Bei ca. 1800 GA´s und 18000 Zuständen in IOBroker wird ein vollständiger Datenaustausch über MQTT ziemlich aufwendig wenn Ich alle Werte einzeln zuweisen muss

Mir ist klar, dass Ich nicht alle benötige .... aber einige werden es schon werden

Grafana:
Da Ich bereits Grafana im einsatz habe, ist es möglich TWS mit dem externen Grafana zu nutzen?

Ich entschuldige mich schon im Voraus für Themen welche im Forum evtl. schon ausführlich besprochen wurden!
Ich hoffe aufgrund der "vielen" Fragen auf Verständnis diesbezüglich

Danke an jeden der sich die Mühe macht bis hierher zu lesen und extra dank an diejenigen die sich mit einer Antwort beschäftigen

[gbglace]

- Das Tunneling über den TWS ist Instabil,

Hmm ich kenne das Tunneling des TWs als sehr stabil, allerdings kenne ich sehr sehr viele Beiträge im KNX-UF die eben über instabile io-Broker KNX Connectoren berichten udn das dieser etwas fern vom Standard implementiert ist. beliebte Workarounds sind da dann Nodered innerhalb des IO-Brokers aufzusetzen. Das aber finde ich absurd.

- Der Download der Datensicherung führt zu Fehler 404 Not Found (Insider Problem?)

Welche Datensicherung auf welchem Themenbereich im TWS?

- KNX Objekte werden erst angezeigt wenn Ich sie dementsprechend in der ETS zuweise

Ja das ist so und einer der wesentlichsten Vorteile des TWs im Zusammenspiel mit dem KNX überhaupt.

Der TWs ist an der Stelle ein echtes eigenes KNX-Gerät und damit kommuniziert er nur mit den Daten des KNX die er auch via seiner KO mit GA verbunden hat.

Der Busmonitor ist eine davon unabhängige Funktionalität, und Container auf dem TWs sind wieder was eigenes weil die einfach via eines IP-Tunnels durch die Schnittstellen Funktionalität des TWS mit dem KNX-kommunizieren. der TWs ist damit schonmal drei Geräte in einem bzgl. des KNX.

Der upload des ETS-Projektfiles in den TWs dient zur Datensicherung und inhaltlich dazu das Du im Busmonitor nicht nur KNX Hex / RAW Werte siehst sondern auch eine dekodierte Sicht hast.
Und in allen Mouseover usw. bezieht der TWS dann auch diese Zusatzinformationen je GA 7 KO usw. um es schön auf den Monitor zu bringen ohne das man als User an allen Objekten das nochmal händisch nachpflegen muss.

kann Ich in der ETS die Zuweisung der DPT irgendwie vereinfachen, oder muss Ich wirklich jeden universalpunkt sauber zuweisen

Es muss jedes Objekt definiert werden. Aber man kann das im Batch mit der Timberwolf Importer APP die es als ETS App kostenlos im KNX-org Shop gibt erledigen.
Da kannst dann die 2000 KO definieren und GA Verbindungen in ein CSV schreiben und dann in die ETS laden. und dann den TWS Programmieren. In der KB des Forums und der Hilfe der App gibt es die Anleitungen dazu.

--> Flags: S Flag nur bei Datenpunkten bei denen Ich auch schreiben möchte (z.B. Schalten Steckdose) oder lasst ihr den immer stehen, weil er eigentlich nicht stört

Es gibt in der KB auch eine sehr gute Seite was die Flags bedeuten.

Das S Flag bedeutet das KO kann vom Bus beschrieben werden. Nicht das Du mit dem TWS via diesem KO eine GA sendest, das macht K+Ü.

--> Flag L: Bei Sensorwerten würde Ich den rausnehmen, da ja der Sensor ausgelesen werden sollte und nicht der TWS ..... kann Ich den Lesen bei Init trotzdem verwenden? oder eher nicht

Das L-Flag gehört im gesamten Bus nur an einem KO je GA gesetzt. Und von Vorteil ist es genau jes KO damit zu versehen welches am besten den Sor repräsentiert. Ein KNX-Tempsensor an einem Taster oder PM bekommt natürlich dort das L-Flag ein Sensorwert der im IoT-Umfeld existiert, bekommt es dann besser am TWs gesetzt weil der TWS die entsprechende Repräsentanz im KNX-Bus ist. Gleiches gilt für 1-wire oder andere Protokolle wo der TWs das GW darstellt.

--> Ist es möglich den K Wert von KNX Objekten irgendwie zu ändern? Damit die mehr Aussagekraft bekommen

Bei ca. 1800 GA´s und 18000 Zuständen in IOBroker wird ein vollständiger Datenaustausch über MQTT ziemlich aufwendig wenn Ich alle Werte einzeln zuweisen muss

Wozu muss da alles auf dem KNX-Bus transportiert werden?
Hast Du soviele Geräte am KNX-Bus der in Seiner Funktion nicht sinnvoll ist wenn da 1800 Funktionen aus dem MQTT nicht ankommen?

Der Vorteil des TWs als Server und KNX-Gerät und GW zu vielen anderen protokollen ist ja, das man nur nioch das über den KNX schieben muss was der wirklich braucht. Also den direkten befehl AN/AUS Lampe.

irgendwelche Sensorwerte Stromzähler usw. braucht es gar nicht unverdichtet auf dem Bus. Das kann man sich per Protokoll x/y in den TWs ziehen hat da seine Timesires und damit das langfristige logging und die passenden Charts / Dashboard im Grafana. Jene Werte die in einer Logik benötigt werden gehen auch ohne Umweg direkt in den LE und nur das Ergebnis geht als Kommando an den KNX.


Daher wird derzeit schon daran gearbeitet die Comet-Visu auch per MQTT-Objekte statt über den KNX direkt anzubinden, da man dann alles fein am KNX vorbei im TWs sammeln kann und nur noch das auf den KNX schreibt und von dem Empfängt was wirklich die direkte Nutzung in den KNX-Geräten erforderlich macht. alles andere was man sonst noch auf der Visu anzeigen will muss dann nicht mehr über den KNX. Ich denke das entlastet in vielen Installationen den KNX schon sehr.

Da Ich bereits Grafana im einsatz habe, ist es möglich TWS mit dem externen Grafana zu nutzen?

Das geht. Sensej ist hier ein User der auch eine externe Grafanainstanz betreibt und die Timeseries DB des TWS dort integriert hat.

Manch einer nutzt da auch den TWs selbst als host für eine eigene Grafanainstanz im Container.

Ich bin nicht gut im Verlinken von Threads ich weis nur das es das schon geschrieben gibt und hab es dann immer grob vor Augen. Und kann Dir daher nur grob beschreiben wo es zu finden ist. Ich schreibe/lese einfach zu viel. Hier und vor allem in KNX-UF.

[Dragonos2000]

Bei ioBroker und KNX habe ich auch mit Abbrüchen gekämpft, das war aber unabängig vom TWS und trat bspw. auch mit einem MDT Router auf. Zwischenzeitlich war das Problem im ioBroker angeblich mit KNX Adapter Version 1.0.20 behoben, um in späteren Versionen wieder aufzutreten. Ich hab's jedenfalls nie 100%ig stabil zum laufen bekommen, egal ob ich einen Enertex, MDT oder den TWS für's Tunneling verwendet habe (die Version 1.0.20 habe ich selbst nicht probiert).

Wenn Du mit "K Wert von KNX Objekten" das vorangestellte "K" im internen Objektsystem meinst: Das kannst Du unter "Objekte & Logik" >> "Subsystem Manager" anpassen

Die Flags sind ein Thema für sich und muss man abhängig von der eigenen Implementierung genau überlegen, Göran hat ja schon etwas dazu geschrieben. Eine pauschale Aussage ist da eigentlich nicht möglich. Vor allem beim L (lesen) genau überlegen, ob der TWS überhaupt reagieren soll. Das wird insbesondere beim Kaltstart des KNX relevant...

[Dragonos2000]

Nachtrag: Das Init-Flag könntest Du bei GAs mit Sensoren setzen, ja. Ich mache das bei mir aber nur, wenn der Sensor nur in großen Zyklen oder nur bei Änderungen sendet, um den Bus nicht unnötig zuzumüllen. Oder dann, wenn ich halt zeitnah einen gültigen Wert bspw. für eine Logik brauche.

[Zelkin]

@gbglace

beliebte Workarounds sind da dann Nodered innerhalb des IO-Brokers aufzusetzen. Das aber finde ich absurd.

Sehe Ich auch so

Welche Datensicherung auf welchem Themenbereich im TWS?

Unter Systemeinstellungen --> System --> Datensicherung
Beim 35XX gibt es keinen MSD karten Slot mehr, dementsprechend würde Ich mir die Datensicherung gerne extern auslagern --> da kommt beim download nun 404 not found

Der TWs ist an der Stelle ein echtes eigenes KNX-Gerät

Genau Davon erhoffe Ich mir ja die Stabilität die Ich suche

Busmonitor ist eine davon unabhängige Funktionalität

Hier hätte Ich es jetzt Gigantisch gefunden wenn man Objekte wie eine Temperatur nicht speziell in der ETS Verknüpfen muss um diese im TWS weiter zu verarbeiten
Die Temperatur könnte sich der TWS aus dem Protokoll nehmen und als Objekt zur Verfügung stellen --> dies kann man dann beliebig weiter verknüpfen
Vorteile:
Weniger "verbrauchte" Verbindungen im Stack
Weniger aufwand durch die Zuteilungen innerhalb von ETS UND TWS
Ich würde mir das in etwa so Vorstellen:
bei den Gruppenadressen setzt man einen Haken bei den Werten die man über den Busmonitor als Objekt haben möchte, und diese kann man dann so weiterverarbeiten als ob sie direkt als KO in der ETS Programmiert wären .... sollte Ich vlt. mal als Feature Request anbringen.

Timberwolf Importer APP

Danke Tolle Info

Das S Flag bedeutet das KO kann vom Bus beschrieben werden

Knoten Im Hirn gehabt ... Iss Klar

K-Wert

Wie auch Dragons2000 schon sagte meinte Ich den Präfix für KNX bzw. Ich bezog mich auf diesen wert
Gemeint hatte Ich allerdings das was nach dem K Kommt
Das KNX Objekt heißt K1 / K2 / K3 ...... da wäre mir "K UG_Flur Licht Weiss Fehler Status" lieber wegen der "aussagekraft"

Wozu muss da alles auf dem KNX-Bus transportiert werden?

Mir geht es eigentlich eher um die andere Richtung!
Ich würde gerne "alle" 1800 GA´s in MQTT schreiben damit Ich diese in IOB weiterverwerten kann --> dabei isse egal ob mit InfluxDB und Grafana oder für die Visu welche auf dem IOB läuft
Ausserdem sollten einige der 18000Zustände meines IOB rüber in den TWS (nicht unbedingt auf den Bus) um z.B. Zustände von Hue Leuchten mitzuteilen oder so ebbes (bin noch am ausklügeln wie Ich alles aufbaue)

Externes Grafane: das geht

Werde Ich finden, danke für den Hinweis

hab es dann immer grob vor Augen

Das Kenne Ich

@Dragonos2000
Ich habe die Probleme auch mit dem MDT Router ....
Ich bin mitlerweile auf den Zahlungspflichtigen v2 gewechselt ... der Support ist jetzt um einiges besser, aber Ich hab einfach keine Lust mehr .... vor allem der Rest vom Huas hat keine Lust mehr am abend einfach kein Licht auf dem Klo zu haben! Desweghen jetzt diese Investition um alles mal zuverlässig hinzubekommen!

Wenn Du mit "K Wert von KNX Objekten" das vorangestellte "K" im internen Objektsystem meinst: Das kannst Du unter "Objekte & Logik" >> "Subsystem Manager" anpassen

Nicht so ganz --> siehe ein paar Zeilen weiter oben

Flags:
bei allen Sensoren sollten die Flags dann doch so aussehen wenn Ich mich nicht Täusche:
KSÜA(I) --> so sollte der TWS alle Werte mitbekommen I nur bei Sensoren welche keine Werte senden bei Initialisierung und lange Intervalle haben oder wenn der TWS den Wert stellt ... dann bekommt er aber auch den L

bei allen Aktoreneigentlich das gleiche? !
Ich hab ja so keien NAchteile oder vorteile bei einer anderen setzung oder

...... Ich lese dies aber im Sub Forum nochmal nach

[StefanW]

Hallo Moderatoren,

wir bräuchten hier noch einen gescheiten Titel für diesen Thread (bitte auch dem TE erklären) und wir müssen ggfls. ein Subforum für komplexere Inbetriebnahmefragen starten.

lg

Stefan

[StefanW]

Hallo Moderatoren,

bitte dem TE auch die Regeln zur Angabe der SW-Version erklären, bin gerade in Zeitnot, danke.

lg

Stefan

[gbglace]

Externe Ziele für die Backups sind noch ein Feature im Werden.

Wunsch ist aber schon erkannt. Zwischen-Schritt wird wohl eine angestöpselte HW sein auf die gesichert werden kann. Es werden aber auch per Netzwerk verteilte Sicherungen angedacht.

Naja das was Du da im Busmonitor sieht sind halt auf einem anderen Kanal empfangene Daten die dann schon in der Timeseries DB liegen. Also nichts was gerade erst wo rein kommt. Ansonsten hat der TWS eben ein stringentes Objekt-Modell. Und das was mit KNX zu tun hat kommt nur via die KO in den TWs, weil dieses System eben genau diesen Stack als Kanal benutzt. Der Busmonitor ist "nur" ein SQL in eine Datenbank. Das ist kein eventbasiertes Objektsystem.

Was in einigen Threads schon diskutiert ist, ist ggf eine Art Reverseprogrammierung zu ermöglichen. Also der TWS kreiert KNX-Objekte in sich selbst und programmiert sich das selbst in den KNX-Stack in eines der 2000-KO. Die Kunst besteht dann das in das ETS-Projekt zurück zu synchronisieren. Zumindest aus Objekten die an anderen System in den TWs einfließen und als solche als Objekt im TWs existieren wäre es dann vorgesehen ein KNX-Objekt zu kreieren (was man eben so in anderen Technologien schon im Verknüpfungsassitenten machen kann). Hier wäre dann wohl eher das GA Register im TWS ein Aufsatzpunkt, nicht der Busmonitor, der ist eben doch recht weit weg von einem der verfügbaren Objektsysteme (SQL auf eine Datenbank)

Das was Du da siehst K1 K2 ist keine Objektbezeichnung sondern schon die eindeutige Objekt ID und die KNX-Objekte beginnen halt mit dem Präfix K und entsprechen sonst genau der Nummer die Du in der ETS je KO siehst. Alles weitere kannst aber in den Objektbeschreibungen / KO Beschreibungen in der ETS oder im Objektmanager ergänzen und vieles davon wird in den betroffenen Dialogen per moseover dann auch angezeigt, wie mittlerweile auch die GA selbst, weil viele User da mehr in den GA als in den KO-Ids der TWS Applikation denken.

[gbglace]

Jo auch ein Hinweis.

Es sind zwar sehr viele allgemeine Sammelfragen die ergeben sich aber wohl immer bei Neueinsteigern wenn man den TWS ausgepackt und angestöpselt hat.

@Zelkin
Aber dennoch macht es Sinn den aktuellen Stand der auf deinem TWS installierten Software im Threadtitel zu ergänzen.
Denn in 3 Jahren findet jemand diesen Thread weil er auch Fragen zu ersten Gehversuche hat. Vieles an Problemen/ Fragen stellt sich dann aber hoffentlich schon gar nicht mehr weil Features dann nachgereicht wurden oder andere Lösungen direkt implementiert wurden. Mit der Sichtbarkeit des Softwarestandes erkennt man schnell das die hier besprochenen Fragen eher nicht mehr relevant sind wenn man dann sieht o ich bin schon auf V 20 und nicht mehr auf V2 oder V3.

Den Footer hast ja schon ordentlich gestellt, den aber nicht mit der SW-Version versehen, weil der Footer als Zusatzinformation zum User immer in der aktuellsten Form an die Beiträge gesetzt wird und nicht statisch wie der Beitrag selbst ist.

[Zelkin]

Hoffe das Passt jetzt besser