UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Gelöst] [V1.6.0 RC4] Logik Editor zeigt Meldung unerwarteter Fehler (WD-1762)

Hier bitte Eure Diskussionen und Feature Requests zu neuen Logikmodulen und Funktionen des Logik-Editors

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#21

Beitrag von Robert_Mini »

Alles richtig.
Vermeidbar nicht wirklich, da dies die Zertifizierung fordert...

Wie gesagt: Schau dir die Importer App an.
Du kannst dann im Excel einen Schwung GAs zusammen sortieren und dann automatisch verknüpfen.

Später dann nach Bedarf weitere hinzufügen, programmieren und Projektdabei importieren.

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Ersteller
daniel29
Reactions:
Beiträge: 42
Registriert: Sa Jul 13, 2019 12:20 pm
Hat sich bedankt: 18 Mal
Danksagung erhalten: 7 Mal

#22

Beitrag von daniel29 »

Robert_Mini hat geschrieben: Mo Sep 07, 2020 2:18 pm Alles richtig.
Vermeidbar nicht wirklich, da dies die Zertifizierung fordert...
Aber der Logikeditor hat doch mit der ETS so nichts zu tun? Der Timberwolf kennt doch aus dem Import der Projektdatei schon die GAs?

Das ist doch eigentlich beim Homeserver neben der Neustart-Sache die größte Krücke, dass man dort nach jeder GA Änderung erst im Experten die Stammdaten wieder nachimportieren muss.

Dann muss es doch zumindest die Möglichkeit geben on the Fly das Objekt zu erzeugen wenn ich jetzt auf eine KNX GA zugreifen will.
Robert_Mini hat geschrieben: Mo Sep 07, 2020 2:18 pm Wie gesagt: Schau dir die Importer App an.
Du kannst dann im Excel einen Schwung GAs zusammen sortieren und dann automatisch verknüpfen.
Die App hab ich. Aber irgendwie ist das ja auch wieder ein eigenes Datenformat, oder? Oder kann ich in dem Format aus der ETS exportieren? Dann könnte man sich einfach alle 4200 Rows exportieren und einfach nur die paar hundert drin lassen die man braucht und nur eine Objektnummer ergänzen und über den Importer importieren.
Zuletzt geändert von daniel29 am Mo Sep 07, 2020 3:05 pm, insgesamt 1-mal geändert.
Timberwolf 2600 #332, VPN offen, Reboot bitte nur nach Absprache

Ersteller
daniel29
Reactions:
Beiträge: 42
Registriert: Sa Jul 13, 2019 12:20 pm
Hat sich bedankt: 18 Mal
Danksagung erhalten: 7 Mal

#23

Beitrag von daniel29 »

es gibt zu der Thematik schon einen Thread
viewtopic.php?f=26&t=1622

Auch wenn wir nicht wirklich klar ist wofür die verknüpften Objekte mit der Timberwolf Applikation in der ETS sinnvoll sein sollen? Ausser für die "Timberwolf eigenen Objekte" wie zB 1Wire Sensoren. Dafür verstehe ich das. Für alles andere ist das doch eher so nen DummyHS Nachfolger und macht eigentlich gar keinen Sinn, oder?

Sind eigentlich die Logic Engine Objekte vergleichbar gedacht zu den iKOs? Also Objekte die ich nur auf dem TW benötige um zB mit einer Logik weiterzuarbeiten?
Zuletzt geändert von daniel29 am Mo Sep 07, 2020 3:18 pm, insgesamt 1-mal geändert.
Timberwolf 2600 #332, VPN offen, Reboot bitte nur nach Absprache

FabKNX
Reactions:
Beiträge: 478
Registriert: Mi Aug 15, 2018 7:50 pm
Wohnort: LK Heilbronn
Hat sich bedankt: 684 Mal
Danksagung erhalten: 247 Mal

#24

Beitrag von FabKNX »

Der TWS ist halt ein richtiges KNX Gerät. Wie bei jedem anderen KNX Gerät reagiert er nur auf GA bzw. die damit verbundenen KO.

Alle anderen ignoriert er.
Nur im Busmonitor lauscht er auf den kompletten Bus-Verkehr.
VG Fabian
TWS 2500
timberwolf138, VPN offen, Reboot jederzeit
follow me on Instagram: https://www.instagram.com/meinsommer_diy/

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#25

Beitrag von Robert_Mini »

FabKNX hat geschrieben: Mo Sep 07, 2020 5:27 pm Der TWS ist halt ein richtiges KNX Gerät. Wie bei jedem anderen KNX Gerät reagiert er nur auf GA bzw. die damit verbundenen KO.
Richtig. Und wichtig: man kann im Gegensatz zur Dummy Applikation mit den Flags arbeiten wie vom KNX Standard vorgesehen, siehe:
app.php/kb/viewarticle?a=122

Und ja: Man die GA als Liste aus der ETS Exportieren und dann zum Massenimport editieren:
app.php/kb/viewarticle?a=94

Ich würde aber anders als beschrieben nur eine Auswahl importieren.

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#26

Beitrag von gbglace »

FabKNX hat geschrieben: Mo Sep 07, 2020 5:27 pm
Nur im Busmonitor lauscht er auf den kompletten Bus-Verkehr.
Und durch das Hochladen des ETS-Projekfiles siehst im Busmonitor nicht einfach nur GA's und PA's und Hexwerte der Telegramme sondern auch ordentlich dekodiert die Einheiten und die fachlichen Ausprägungen.

Ansonsten, reduziert sich alles auf die Erklärung, der TWS ist ein echtes KNX-Gerät und alle Logiken usw. funktionieren auch ganz ohne einen Upload des ETS-Projekt-files, weil der TWS eben auf genau das reagiert was ihm durch die ETS mitgeteilt wurde.

Dieses Prinzip findest Du auch bei allen anderen Kommunikationskanälen von und zum TWS. Es werden immer Objekte angelegt auf die dann innerhalb des TWS intern reagiert wird und die man miteinander verlinken kann.

Eine GA ist nunmal kein Objekt, eine GA ist Teil eines KNX-Telegrammes über den ein jedes Kommunikationsobjektes für sich eintscheiden kann (unterzuhilfenahme der am KO konfigurierten Flags) inwieweit es von diesem Telegramm betroffen ist. Wenn Betroffenheit erkannt wird, wird der Dateninhalt ( 0/1 oder 0-255 oder was auch immer der Datentyp hergibt) in die internen Objekte eines jeden Gerätes durchgereicht. Dem gerät ist damit die GA selbst als Information nicht mehr bekannt und ist auch völlig irrelevant, da eben ein Objekt auf mehrere GA hören kann, für das Kommunikationsobjekt ist es aber egal woher es die Information 0 oder 1 erhalten hat.

Die Funktionalität des Busmonitors und des daran angeschlossenen separaten Ringspeichers für das KNX-log ist eine davon losgelöste Funktionalität im TWS.

Andere Hersteller ticken da eben anders, dafür hat man dann dort aber auch gleich andere Probleme die in den Foren auch immer wieder diskutiert werden (Dummy-Applikation, Filtertabellen, eigenartige Telegrammwiederholungen weil keine ACK gesendet werden).

Gerade im Zusammenhang mit den anderen Bussystemen ist der TWs an der Stelle konsequent und sauber und einheitlich. Im reinen Kontext KNX ggf anders, aber dafür ist KNX eben auch nur ein Protokoll für den TWS. Wenn du irgenwann rein via MQTT und oder Modbus Systeme miteinander verbindest spielen GA#s überhaupt keine Rolle, im Zweifel haben Kunden gar keine KNX-Komponenten in dem ganze System. Warum dann also an der Stelle ein andersartig funktionierendes System einbauen?

Man kann natürlich für jede GA ein KNX-KO im TWS anlegen (was die KNX-org derzeit aber noch nicht schafft zu realisieren in deinem Fall).
Man kann aber auch einfach nur jene KO anlegen womit man auch wirklich arbeiten möchte. Und dabei kann man sich überlegen, muss KO zu GA auf der Eingangsseite eine 1:1 Beziehung sein oder könnte auch je KNX-bezogenen Logikeingang ein KO gegeben sein und in der ETS entscheidest dann welche GA dieses KO bedienen können sollen, weil man ja mehrere GA an ein KO als Eingang verbinden kann.

Bei den Ausgangsobjekten macht es dann natürlich sinn 1:1 GA und KO vorzusehen, da ja wohl jeder dieser Ausgänge eine spezifische Funktion repräsentiert und man dies dann über GA definiert im KNX-Umfeld.
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

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

#27

Beitrag von StefanW »

Hallo Daniel,

Du hast ja schon eine Menge Antworten bekommen, darum nur noch ein paar kleine Anmerkungen
daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmdas klingt irgendwie so mittel. Es sind doch alle Telegramme auch auf dem Busmonitor drauf? Das könnte doch irgendwie out of the box gehen?
Nein, weil in den Daten-Telegrammen (es gibt noch System-Telegramme) befinden sich (neben ein paar Flags) vor allem nur zwei Felder.

1. Eine 16 Bit Adresse (das ist die GA)
2. Ein Datenbereich von 1 Bit bis 14 Byte (überwiegend, es gibt noch Spezialformate).

Diese paar Byte sind das einzige was man am Busverkehr sieht, daraus kann man nicht wirklich viel ablesen.


A. Aus der 16 Bit Adresse weiß man nicht, wie der Kunde diese in der ETS für sich formatiert hat (also Einstellig, Zweistellig oder Dreistellig)

B. Aus den Daten weiß man überhaupt nicht, wie diese zu interpretieren sind. Bei einem Bit ist das noch einfach, aber bei 8 Bit. Ist das nun eine Zahl? Oder ein Prozentwert (den es schon in zwei Arten gibt)? Oder ein Buchstabe? Oder ein spezielles Bitmuster, das auszuwerten ist?

Der Busverkehr gibt im Wesentlichen nur die nackte Funktionsadresse (als Gruppenadresse bezeichnet) und ein Bitmuster her. Damit kann man gar nichts Out-of-The Box machen.

Deshalb sieht der KNX Standard ja auch vor dass Sender und Empfänger dahingehend eingestellt werden müssen, wer sich wann wie angesprochen fühlt, wie die Daten zu interpretieren sind und was damit passieren soll.

Bei KNX Geräte nimmt man dazu die ETS und stellt dort ein, welche der Objekte eines Gerätes aktiviert werden (sofern das auswählbar ist) und mit welchen GAs (das können eingehend bis zu 16 GA sein) diese Objekte verknüpft werden und vor allem wie die Daten zu interpretieren sind durch Angabe des Datenpunkttyp.

Ein jedes Gerät muss letztlich mindestens den DPT der GA wissen (genauer des Objektes).

daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmOhne diesen Umweg. Das führt ja eigentlich nur zu vermeidbarem Aufwand beim Nutzer.
Der KNX Bus erlaubt sehr komplexe und vielfältige Einstellungen und ist sehr skalierbar. Ohne ordentliche Definition der Linien, der Adressen, der GAs, der Datenpunkte und die Zuordnung zu den Objekten in den KNX Geräte läuft es nicht.

Das ist kein Umweg, sondern das Definieren dieser Parameter ist eine betriebliche Notwendigkeit. Weil sonst die empfangenden Geräte nicht wissen, wann sie gemeint sind und wie die Daten zu interpretieren sind. Weil der Empfänger sieht ansonsten nur ein Bitmuster und alleine hinsichtlich der DPT gibt es mehrere hundert Interpretationen die auf knapp 200 A4 Seiten niedergeschrieben sind. Einfach raten oder annehmen geht nicht. Es muss schon angegeben werden. Mag mühsam sein, muss man aber auch bei Modbus, MQTT und allen anderen Protokollen machen mit dem Unterschied, dass es dort keinen Standard für die Kodierung gibt sondern man das mühsam für jedes Gerät erstmal herausfinden muss.

KNX mag einem da akribisch und aufwändig vorkommen. Da muss man erstmal die anderen Bussysteme sehen, dann wird man KNX die "Hand küssen" für den Komfort den es dort gibt.

Theoretisch gibt es drei Varianten, woher ein KNX Gerät weiß, wie die Daten zu interpretieren sind.

A: In der Applikation weitestgehend festgelegt: Der mögliche DPT ist vom Gerätehersteller intern bereits festgelegt und die "Applikation" (die Datei mit den Definitionen aller Objekte eines KNX Gerätes) kennt diese DPT und die ETS liest das entsprechend aus und gestattet nur die Verknüpfung mit passenden GAs eines kompatiblen DPT (gibt Ausnahmen)


B: Durch ETS festgelegt: Der DPT wird durch Programmierung mit der ETS festgelegt zusammen mit den verknüpften GAs. So machen wir das beim Timberwolf Server. Es ist ähnlich wie A, also das was alle anderen Geräte machen. Nur hat der TWS sogenannte Universalobjekte, die es dem Kunden ermöglichen, das beliebig festzulegen. Das erlaubt dem Nutzer sehr hohe Freiheitsgrade aber macht es eben auch notwendig die Objekte anzulegen, die Flags zu spezifizieren und die Objekte mit den GAs zu verbinden


C: Irgendwie definiert: Das Gerät bekommt Informationen zu GAs / DPT auf einem anderen Weg. Also durch irgendein Flashen, durch Eintippen oder durch das Einlesen der Projektdatei.

Letzteres ist kein offizieller Weg im KNX Standard, weil hier eine Menge wesentlicher Details fehlen:

C1: Problem Filtertabellen: Dem ETS Projekt ist nicht mehr bekannt, wer alles Empfänger eine GA ist und in welcher Linie diese sitzen. Damit kann keine Berechnung von Filtertabellen vorgenommen werden für Linienkoppler / Bereichskoppler / Router. Um das zu umgehen braucht man eine Dummyapplikatíon pro solchem Gerät, macht die Arbeit dann aber doppelt (im Gerät definieren und in der Dummyapplikation)

C2: Problem keine Flags: Mit Flags wird gesteuert wie ein Objekt in Bezug auf den Bus reagiert (lesen, schreiben, automatisches Lesen on Init usw). Die Nutzung und Wirksamkeit dieser Flags ist ziemlich erheblich für verschiedene Funktionen und insbesondere wenn es darum geht, welcher Sender eigentlich "das Sagen" hat. Hierdurch wird auch das saubere Anstarten einer KNX Installation, z.B. nach Stromausfall, besser gesteuert. Solche Flags gibt es nur auf Objekten, nicht auf GAs. Insofern verzichten alle "nur GA-Produkte", die damit nicht voilständig KNX kompatibel sind, auf wichtige Einstellungsmerkmale. Wissen nicht viele, aber die Flags sind durchaus brauchbar.

daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmDas heißt ich muss mir jetzt überlegen welche KNX Objekte ich für meine Logik nutzten will und die dann erst in der ETS mit dem Timberwolf verbinden.
Richtig. Weil es der KNX Standard so vorsieht. Alle zertifizierten KNX Geräte arbeiten intern mit Objekten die von außen mit einer oder mehreren (bis zu 16) GAs verbunden und mit Flags versehen werden.

Ich lese aus Deinen Worten den Vorwurf heraus, dass dies ja kompliziert wäre.

Wir mussten eine Entscheidung treffen. Designen wir den Server hinsichtlich KNX fachlich korrekt und damit per ETS programmierbar oder machen wir einen fachlich falschen GA-Server. Letzteres mag auf den ersten Blick einfacher wirken, aber macht tatsächlich ein paar Probleme die man erst im späteren Betrieb merkt bzw. wenn es an Details geht. Göran hat dazu oben etwas geschrieben.

Wir haben uns entschieden, dass der Timberwolf Server eine KNX Zertifizierung bekommen soll und damit sind seine Objekte auch zu programmieren und deshalb muss der Kunde sich nun Gedanken machen und die nötigen Objekte erstmal aktivieren und dann verbinden. Dafür gibt es dann Filtertabellen und feingranulare Kommunikationseinstellungen via Flags. Zudem wird damit auch das für eine sparsame Bandbreitennutzung wichtige Konzept des Mappings mehrerer GAs auf ein Objekt (X GA -> 1 Objekt) unterstützt. Das spielt in der Praxis ebenfalls eine große Rolle.

daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmQuasi wie bei Gira der DummyHS?
Nein. Die Dummy-Applikation für den HS ist nur dahingehend nützlich, dass die ETS weiß wo (ein weiterer) Abnehmer des GA physisch angeschlossen ist und kann deshalb die Filtertabellen richtig berechnen und programmieren. Nebenbei hilft es Ordnung zu halten. Allerdings muss der Nutzer da immer aufpassen, dass beides manuell synchron eingestellt ist (ist also fehlerbehaftet), es gibt keine Flags auf Objekten und man muss es doppelt machen.

Beim Timberwolf Server legt man die Objekte nebst GAs an, programmiert und fertig. Da muss man nichts doppelt machen, weil der TWS ja dann die Objekte kennt und sofort kommunizieren kann.

daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmIch muss jetzt also erstmal in der ETS unter Universalobjekte mir welche aktivieren und dabei den richtigen Datentyp auswählen?
Ja. Der Server kann den DPT nicht erraten. Die Freiheit alles einstellen zu können bedingt auch die Notwendigkeit, alles einzustellen.

daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmund dann die GAs verknüpfen und danach über die ETS programmieren?
Richtig. Wie bei jedem anderen KNX Gerät auch. So hat man alle Einstellungen eines KNX Netzes auch im Projekt.

daniel29 hat geschrieben: Mo Sep 07, 2020 1:49 pmund danach auch noch wieder die Projektdatei in die Weboberfläche importieren?
daniel29 hat geschrieben: Mo Sep 07, 2020 3:14 pm es gibt zu der Thematik schon einen Thread
viewtopic.php?f=26&t=1622

Auch wenn wir nicht wirklich klar ist wofür die verknüpften Objekte mit der Timberwolf Applikation in der ETS sinnvoll sein sollen? Ausser für die "Timberwolf eigenen Objekte" wie zB 1Wire Sensoren. Dafür verstehe ich das. Für alles andere ist das doch eher so nen DummyHS Nachfolger und macht eigentlich gar keinen Sinn, oder?

Sind eigentlich die Logic Engine Objekte vergleichbar gedacht zu den iKOs? Also Objekte die ich nur auf dem TW benötige um zB mit einer Logik weiterzuarbeiten?
Nein. Das ist NICHT notwendig für die Nutzung der Objekte innerhalb des Servers.

Aber der Import des ETS-Projektes ist für zwei Dinge hilfreich

Erstens kann der Busmonitor dann den nebenbei aufgezeichneten Datenverkehr auch dekodieren, weil er die 16 Bit Adressen der in der ETS verwendeten PAs sowie der GA zuordnen kann und weil er dann auch den DPT kennt und damit den Dateninhalt des Paketes dekodieren kann. Wenn man das Projekt nicht importiert, dann hat man eben nur die aufgezeichneten Bitmuster bzw. deren Hexcodes. Wer das lesen kann, kann sich auch den Import der Projektdatei sparen.

Zweitens kennt die Oberfläche an vielen Stellen alle dies Details wie Gerätenamen, GAs, Haupt- und Mittelgruppen und nach vielem davon (noch nicht nach allem, aber das wollen wir noch verbessern) kann man auch suchen, so dass man nicht die Objekte wissen muss.

Mein Rat: Während der heißen Implementierungsphase, wenn man womöglich mehrmals im schnellen Wechsel die Objekte definiert in der ETS und den TWS von dort programmiert, würde ich auf das Einlesen der Projektdatei erstmal verzichten bis man damit durch ist und erst am Abend oder am Schluss einer solchen Implementierungsrunde würde ich mir die Arbeit machen und die Projektdatei einlesen. Zum einen wird diese sehr wertvolle Datei dadurch auf dem Server gesichert, es gibt eine (übrigens tolle!) Auswertung ob alles konsistent zueinander ist bezüglich der DPT (weil die ETS lässt dort mehr Freiheiten zu als wir gut finden) und man hat im Server alle die Bezeichnungen und Beschreibungen für alles und jedes.

daniel29 hat geschrieben: Mo Sep 07, 2020 3:14 pmAuch wenn wir nicht wirklich klar ist wofür die verknüpften Objekte mit der Timberwolf Applikation in der ETS sinnvoll sein sollen?
Wie gesagt, das gilt für alle KNX Geräte so.

Was einem womöglich am Anfang gedanklich ungewohnt vorkommt ist, dass man bei üblichen KNX Geräte eine festgelegte Funktion im Gerät hat (also z.B. ein Aktor) und man daher nur die Seite kennt, den Aktorkanal einzuschalten, Optionen zu parametrieren, ein oder mehrere GAs verbinden und fertig. Da "sieht" man die Objekte in dem Gerät nicht so richtig bzw. macht sich darüber keine Gedanken.

Beim Timberwolf Server ist das anders, dort sieht man die Objekte auf beiden Seiten. Zum einen von der ETS Seite um diese zu aktivieren, einen DPT zuzuweisen und mit ein oder mehreren GAs zu verbinden. Und dann, wenn man sich darauf eingeloggt hat sieht man diese Objekte auf der "anderen" Seite um diese nun beliebig innerhalb des Objektsystems verknüpfen zu können. Letzteres ist ungwohnt und man mag zunächst der Meinung sein, dass man das doch gar nicht braucht.

Tatsächlich wird alles im Server durch ein Objekt präsentiert: 1-Wire, Logikpunkte, Zeitserien, ekey aber bald auch schon Modbus, MQTT, DMX usw.

Die mit der ETS angelegten Objekte sind im TWS auch nur Objekte vom Typ KNX-TP und man kann ALLE Objekte miteinander verbinden (kompatible Datenformate vorausgesetzt und es sind entweder "Nur-Empfangs-Objekte" oder "Nur-Sendende-Objekte").

Das Objekt habe ich an dieser Stelle näher erklärt und ich bitte Dich, hier weiterzulesen. viewtopic.php?f=22&t=2363&p=26226&hilit=knxmane#p26227

daniel29 hat geschrieben: Mo Sep 07, 2020 3:14 pmAusser für die "Timberwolf eigenen Objekte" wie zB 1Wire Sensoren. Dafür verstehe ich das.
Fein. Aber bitte daran denken. Alles im Timberwolf Server ist letztlich das Objekt eines Subsystems einer Technologie.

daniel29 hat geschrieben: Mo Sep 07, 2020 3:14 pmSind eigentlich die Logic Engine Objekte vergleichbar gedacht zu den iKOs? Also Objekte die ich nur auf dem TW benötige um zB mit einer Logik weiterzuarbeiten?
Logik Objekte des Timberwolf Servers sind Objekte der Technologie "Logik Engine". Diese Technologie existiert nur intern. So wie Zeitserie auch. für die Kommunikation nach extern verknüpft man diese Logik-Objekte mit entsprechenden Objekten eines Subsystems, das zu einer Technologie gehört, die über ein Bussystem oder ein Protokoll nach außen kommunizieren kann.

daniel29 hat geschrieben: Mo Sep 07, 2020 2:57 pmAber der Logikeditor hat doch mit der ETS so nichts zu tun? Der Timberwolf kennt doch aus dem Import der Projektdatei schon die GAs?
Jein. Ansich sind die GAs intern gespeichert, aber der Server arbeitet intern auf Basis von Objekten, nicht auf Basis des Adressierungsschemas des jeweiligen Protokolls.

Das Objektsystem stellt eine Abstraktionsschicht der jeweiligen Technologie dar und vereinfacht das Verknüpfen. Sonst würde man ja "1-Wire Seriennummern und deren Register" verknüpfen mit GAs und diese mit "Modbus-Adressen und deren Registern". Und wo passieren dann die Umrechnungen?

Sehen wir uns einen 1-Wire Sensor an. Der hat eine 1-Wire-AdressID und mehrere Register mit Werten drin. Das sind aber zum Teil rohe Werte die umgerechnet werden müssen. Das stellt man im 1-Wire Regeleditor ein. Dazu noch ein paar Parameter und am Ende entsteht dadurch ein "1-Wire Objekt" (das man übrigens beliebig benennen darf).

Mit Modbus wird das auch so sein, da wird man die Adresse hinterlegen, die Register und wie das alles ggfls. umzurechnen und zu bewerten ist. Daraus wird dann ein Modbus-Objekt erzeugt. Genauso läuft das mit Zeitserien, ekey Authentifizieren (der linke Finger von Marta an der Haustüre ist dann ein ekey-Objekt). Das kann man nun noch für Dutzende weitere Technologien spinnen. Überall gibt es Einstellungen die am Ende zu einem leicht handhabbaren Objekt führen.

Diese Objekte kannst Du nun verknüpfen. Beinahe beliebig. Das ist ein Granatenvorteil und eine erhebliche Vereinfachung in der Handhabung. Sobald man das verstanden hat.

daniel29 hat geschrieben: Mo Sep 07, 2020 2:57 pmDas ist doch eigentlich beim Homeserver neben der Neustart-Sache die größte Krücke, dass man dort nach jeder GA Änderung erst im Experten die Stammdaten wieder nachimportieren muss.
Es ist schon was anderes.

Also Neustart gibt es beim Timberwolf Server normalerweise praktisch gar nicht (außer BIOS und Kernel Update). Eine Änderung an eine Logik ist in 1/20 s. bewirkt. Nix Neustart deswegen.

Wenn man im KNX System irgendwelche GAs neu definiert dann muss man alle beteiligten Komponenten programmieren. Wenn der TWS nun auch so ein KNX Gerät ist, dass mit der GA verknüpft werden soll, dann ist das eben so. Dieses Zuordnen und Programmieren ist das ist das Kerndesign des KNX Systems. Es mag umständlich erscheinen, schafft aber Ordnung und Stabilität.

daniel29 hat geschrieben: Mo Sep 07, 2020 2:57 pmDann muss es doch zumindest die Möglichkeit geben on the Fly das Objekt zu erzeugen wenn ich jetzt auf eine KNX GA zugreifen will.
Darüber überlegen wir, die betreffende Idee hast Du auch schon gefunden. Wir müssen das noch mit der KNX Association besprechen ob es ok ist, dass wir uns selbst programmieren. Vermutlich steht dem entgegen, dass die ETS das dann nicht weiß und das kann zu Unordnung im Projekt führen. Das mag zwar eine pragmatische Arbeitsweise sein, aber es ist keine saubere Arbeitsweise.

Sind der HS und alle anderen auf GAs basierenden Server auch nicht und werden trotzdem akzeptiert.

daniel29 hat geschrieben: Mo Sep 07, 2020 2:57 pmDie App hab ich. Aber irgendwie ist das ja auch wieder ein eigenes Datenformat, oder? Oder kann ich in dem Format aus der ETS exportieren? Dann könnte man sich einfach alle 4200 Rows exportieren und einfach nur die paar hundert drin lassen die man braucht und nur eine Objektnummer ergänzen und über den Importer importieren.
Bitte nochmal ansehen, aber die Kunden haben das geschafft, dass man die GAs exportiert hat, haben sich ausgesucht welche sie davon brauchen und haben dafür Objekte angelegt.

Aber: Es ist eine Stärke von KNX, dass man bis zu 16 Objekte auf eine GA geben kann. Das verringert den Datenverkehr. Wenn man nun halbautomatisch für alle GAs ein Objekt anlegt, dann ist das zwar technisch in Ordnung, aber ein wenig vergibt man sich die Möglichkeit mit mehreren GAs pro Objekt zu arbeiten. Aber das ist auch Geschmackssache und es kann sein, dass es nur in größeren Projekten von Bedeutung ist.

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.
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Logik (Module & Editor)“