[NEUHEIT] [V 1.6 IP 2] NEUE "Version 1.6 - Insider Preview 2" ab SOFORT verfügbar - Alle Modellversionen

Neue Produkte, Rollouts, Änderungen, Aktionen
Antworten

Wie war Eure Erfahrung mit der Installation dieses Upgrades (Antwort nachträglich änderbar)

Umfrage endete am Sa Jun 27, 2020 5:37 pm

Erfahrung: Alles Super, keine Probleme bisher
57
79%
Erfahrung: Installation hat gut funktioniert, aber kleine Probleme im Anschluss festgestellt
8
11%
Erfahrung: Hatte größere Probleme mit dem Update selbst bzw. danach
3
4%
Ich warte erstmal ab und beziehe die Insider Preview erst in ein paar Tagen
1
1%
Ich warte etwas länger ab und beziehe die Insider Preview wohl erst in einer Woche oder später
3
4%
 
Insgesamt abgegebene Stimmen: 72


Sun1453
Reactions:
Beiträge: 683
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 441 Mal
Danksagung erhalten: 304 Mal

#61

Beitrag von Sun1453 »

Ahh stimmt ihr habt das ja nicht mit drin, wie beim 950 / 960. Okay Lightengine gibts jetzt noch nicht.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache


geos
Reactions:
Beiträge: 21
Registriert: Sa Mär 16, 2019 10:51 pm
Hat sich bedankt: 127 Mal
Danksagung erhalten: 5 Mal

#62

Beitrag von geos »

Ja, ich hatte für diesen Sommer auch auf die Lightengine gehofft. Mache mir jetzt schon ein wenig Sorgen, dass ich gar nichts mehr davon lese.
TWS 950 ID:324 VPN:offen, Neustart:erlaubt


Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 4153
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 1836 Mal
Danksagung erhalten: 3200 Mal
Kontaktdaten:

#63

Beitrag von StefanW »

geos hat geschrieben:
Fr Mai 08, 2020 4:22 pm
Ja, ich hatte für diesen Sommer auch auf die Lightengine gehofft. Mache mir jetzt schon ein wenig Sorgen, dass ich gar nichts mehr davon lese.

Vorab:
Wir haben Euch und uns in der Vergangenheit mit Ankündigungen keinen Gefallen getan, weil wir oft zeitlich nicht das geschafft haben, was wir uns vorgenommen haben. Daher werden neu bereitgestellte Leistungsmerkmale nach Möglichkeit künftig erst dann angekündigt, wenn diese binnen ein oder zwei Wochen dann auch - zumindest in einer Insider Preview - zur Verfügung stehen.

Diese geänderte Informationspolitik kann man daran erkennen, dass neue Implementierungen wie Persistenz der Logikengine, ekey oder die letzte Woche veröffentlichte KNX Schnittstellenverwaltung usw. erst kurz vor Verfügbarkeit angekündigt wurden.

Das wir derzeit über MODBUS und MQTT schreiben, ist auch nur deswegen, weil wir darüber im letzten Jahr schon geschrieben hatten und die Developer auch auf Teile bereits Zugriff haben. Aber ansonsten wollen wir uns - so gut ihr uns lasst - mit Details zurück halten, weil uns unsere Ankündigungen der Vergangenheit - und vor allem die Verspätungen - teils sehr kritisch nachgetragen wurden.

Dass wir die allermeisten Leistungsmerkmale zwar verspätet aber dann tatsächlich zigfach besser und leistungsfähiger ausgeführt haben und parallel noch akute Kundenwünsche berücksichtigt haben, blieb bei solchen Kritiken unerwähnt.


So wie ich das beobachte, verändert sich die heutige Gesellschaft zu einer Bewertungsgesellschaft. Leider zu einer oberflächlichen. Die öffentlichen kritischen Bewertungen werden überwiegend nicht von professionellen Kritikern verfasst die sich um eine gewisse Ausgewogenheit bemühen, sondern vielfach von Menschen, die sich offenbar gerne hervortun wollen und im Internet nun eine Plattform finden. Mir scheint, dass manchen dieser Menschen das sich selbst hervorheben wichtiger als Fakten.

Das ist eine ungute Entwicklung, weil man selbst mittlerweile weniger mit der Informationsgewinnung beschäftigt ist als mit dem Filtern zwischen all dem Müll. Begünstigt wird dies durch die Neigung vieler Menschen, dass vor allem negative Nachrichten unsere Aufmerksamkeitsschwelle durchbrechen und falsche Meldungen zudem die "spannendere Story" darstellen.

In der Folge führt dies nach meinen Beobachtungen immer mehr dazu, dass Hersteller vorsichtig werden und vor allem nur noch allglatte Nicht-Informationen verbreiten. Das Gefühl wird wichtiger als technische Daten. Solche Informationen zu technischen Details lassen sich dann auch immer weniger finden, dafür großformatige Bilder mit glücklichen Menschen die gerade eine Apps bedienen.


Als ein Unternehmen, das auch im Internet agiert und dessen Produkte in Foren besprochen werden, müssen wir uns an diese Entwicklung anpassen und das bedeutet für uns, vermehrt darauf zu achten, dass unsere Aussagen möglichst massenkompatiblel sind und wenig angegriffen werden können. Entsprechend müssen wir uns mit mancher Transparenz - für die wir von manchen geliebt werden - künftig leider etwas zurückhalten, weil uns diese nicht nur positiv zugerechnet wird sondern von manchem genutzt wird, um uns zu kritisieren.

Insofern bitte ich um Verständnis, dass wir uns mit detaillierten Angaben zu künftigen Entwicklungen zunehmend zurückhalten möchten. Manchmal rutscht mir noch was durch in der eigenen Begeisterung, aber ich arbeite daran, vorsichtiger zu werden.


Thema DMX:

Das Thema DMX ist ein solches schweres Thema, da wir das schon vor sehr vielen Jahren angekündigt hatten und das wir längst für alle Nutzer am Start haben wollten. Mit den Hutschienenversionen funktioniert es auch schon seit Mitte 2019, auch wenn es noch an einer schönen Oberfläche fehlt. Für Desktop-Server ist die Lösung noch auststehend, weil die nötige Hardware zwar schon lange entwickelt aber bislang noch nicht erhältlich ist.


Tatsächlich ist das Thema DMX sehr viel komplexer als es auf den ersten Blick aussieht.

Starker Datenstrom: Im Gegensatz zu KNX, MODBUS, MQTT und DALI verfügen die Endgeräte bei DMX i.d.R. nicht über eine eigene Intelligenz (sprich einen lokalen Dimmer) sondern es sind Slaves die ein Signal direkt und ohne jede Berechnung, Kontrolle usw. direkt umsetzen. Damit muss ein DMX Master einen permanenten Datenstrom von ca. 250 kBit senden um 512 Kanäle zu bedienen, wobei die gesamte Dimmberechnung (inkl logarithmischer Anpassung) für alle diese Kanäle im DMX-Master erfolgen muss. Gegenüber den 9,6 kBit/s bei KNX ist das schon ein Unterschied, zudem wollen wir dies auf mehreren DMX Kanälen parallel ermöglichen.

Göran hat berichtet, das manches Produkt des Wettbewerbes damit dann auch seine Probleme damit hat, weil dort die Dimmberechnung immer nur für eine Leuchte gleichzeitig möglich ist und bei Eintreffen eines neuen Dimmkommandos über KNX der laufende Dimmprozess suspendiert wird um den neuen Dimmprozess zu berechnen. Dass es Hersteller gibt, die sowas tatsächlich auf dem Markt verkaufen verwundert mich sehr. Damit würde ich mich nie zufrieden geben, ich möchte das hunderte von Dimmprozessen parallel möglich sind, auch wenn das vermutlich so auch niemand benötigt. Aber für den Timberwolf Server gilt "No Limits". Diese Leistung soll pro DMX-Univers möglich sein, wobei mehrere DMX Interfaces für mehrere DMX Universes anschließbar sein sollen.

==> Kurz, ich wollte eine vielhundertfache Leistung dessen, was durchaus am Markt in KNX-to-DMX Gateways verkauft wird.


Dazu waren eine ganze Reihe von Entwicklungen erforderlich, die wir auch gestemmt haben:

1. Die Entwicklung des universellen Objektsystems und des Dispatchers geht eigentlich auf diese Anforderung des DMX zurück. Ursprüngliche Planung war, dass wir alle Signale über die Logikengine verknüpfen. Das hätte aber viel Last für die Logik bedeutet und womöglich wäre dann zum Berechnen der virtuellen DMX Dimmer keine Zeit geblieben. Daher haben wir beschlossen, die "Verteillast" zwischen Objekten von der Logikengine zu nehmen und durch einen dafür optimierten Dispatcher zu übernehmen. Das wir damit dann das - so wichtige - universelle Objektsystem mit der extrem einfachen und leistungsfähigen Verknüpfbarkeit geschaffen haben, war dann ein zuseätlicher Gewinn. Aber es war ursprünglich für die DMX Implementierung geschaffen worden, was uns dann auch fast ein dreiviertel Jahr bis zum Release aufgehalten hat.

2. Um die Logik noch weiter zu entlasten, haben wir die eigentlich fertige Entwicklung der Firmware im DMX-CoProzessor komplett neu begonnen um einen Befehlspuffer, synchrone Abarbeitung und Dimmberechnung im CoProzessor hinzuzufügen.

Klingt einfacher als es ist, aber dem ElabNET Ingeniör ist nix zu schwör und daher haben wir das Mitte 2019 realisiert und in den 950er / 960er auch mit den normalen Updates ausgerollt. Das überragende Ergebniss ist, dass wir im Labor 900 LEDs (mehr hatten wir nicht) auf zwei DMX Universen permanent parallel und gleichzeitig dimmen konnten und das dies gerade mal 12% der Rechenleistung gekostet hat.

Ja, wir machen es uns manchmal schon schwer, aber wir mögen unsere Technik richtig und vollgasfest. Vermutlich übertreiben wir es damit, denn 90% der Nutzer werden diese Leistung weder benötigen noch positiv honorieren.

3. Mittlerweile haben wir auch ein "Langzeit-Dimmer" Modul für die Logik entwickelt, womit auch Langzeit-Dimm-Prozesse möglich sind. Ursprünglich entwickelt wurde es ebenfalls für den Eisnatz mit DMX, aber genutzt werden kann es auch für langsame Langzeit-Dimmprozesse für KNX-Dimmer oder DALI (via KNX) usw.

4. Desktop-Server haben keine eingebaute DMX Schnittstellen, daher haben wir in 2019 eine externe DMX Schnittstelle mit CoProzessor entwickelt, die auch bereits seit längerem im Test-Einsatz ist und von den Entwicklern für die SW-Entwicklung genutzt wird. Die aktuelle Software erkennt diese Schnittstelle auch schon und quittiert das mit einem Pieps.

Hier ein Schnappschuss vom DUAL-DMX Modul:
2020-02-20_DMX-Mdoul_Schnappschuss.jpg

Letzte Arbeiten für die vollständige Unterstützung von DMX für Desktop-Server:

A. Interface-Verwaltung und Einbindung in das Subsystem: Die beiden DMX Interfaces (Single- und Dual-Version) wird also bereits (seit langem) erkannt, aber es soll auch über die Oberfläche verwaltet werden können. Wer die letzten beiden Insider Previews kennt, hat gesehen wie diese Art von Verwaltung Schnittstellen nun aussíeht, weil wir das mit den ekey Controllern und den KNX Interfaces nun gezeigt haben. Für DMX haben wir diese "Extension"-Verwaltung bereits designed und anprogrammiert, das liegt nun zur fertigen Umsetzung bei der Entwicklung.

==> Sobald dies umgesetzt ist, wird DMX vollständig genutzt werden können für die Desktop-Versionen der Timberwolf Server und zusätzlichen können diese zusätzlichen Schnittstellen dann auch von den Hutschienenversionen genutzt werden. DMX wird dann angesteuert über die Logikengine zusammen mit dem bereits verfügbaren Modulen "Langzeitdimmer" und "virteller DMX Dimmer".

B. Grafische Dimmverwaltung: Der weiterer Schritt wäre dann eine Oberfläche mit der man die Dimm-Aufgaben usw. grafisch verwalten kann. Dies ist nicht unbedingt notwendig, da auch der Logikeditor grafisch funktioniert, aber es mag ein wenig komfortabler sein.


Lighting Engine vs. DMX

Die Lighting Engine ist nicht gleichzusetzen mit der vollständigen Implementierung von DMX, das sind zwei verschiedene Dinge.

Die Lighting Engine soll ein technologieunabhängiger Szenencontroller werden, d.h. damit soll man Lichtstimmugen steuern können, egal ob die Lampen in einem Abschnitt total gemischt mit KNX, DMX, DALI, HUE usw. angesteuert werden.

==> Die Lighting Engine würde das DMX Modul nutzen, aber das DMX Modul funktioniert auch ohne Lighting Engine.

Mehr möchte ich dazu nicht schreiben. Ich habe hiermit nichts versprochen oder gar avisiert und schon gar keine Termine genannt. Die Dinge an denen wir arbeiten sind fertig wenn sie fertig sind und fertig ist es erst dann, wenn es auch wirklich gut gelungen ist. Es gibt keine Alternative zu Qualität, auch wenn es dauert. Auch wenn ich die Wünsche verstehe, die nach teils langer Wartezeit eine baldige Realisierung anmahnen, denken wir, dass niemand etwas von schlechter Technik oder schwieriger Bedienung hat und sich am Ende herumärgern möchte. Das Thema DMX ist - in Verbindung mit der Oberfläche - leider kompliziert, zudem haben unsere Kunden auch noch viel weitere Wünsche.

Wir wollen dass Ihr Spaß habt mit den Leistungsmerkmalen des Timberwolf Servers. Das ist unser Antrieb und das sind dann auch die Qualitätsvoraussetzungen.

Das speziell DMX sich so ewig bis zur Realisierung bei den Desktopservern hinzieht tut uns sehr leid und wir entschuldigen uns bei allen, die teils schon jahrelang darauf warten und akzeptieren die Prügel, die wir zu Recht von manchen bekommen.


lg

Stefan
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von StefanW am Sa Mai 09, 2020 5:36 pm, insgesamt 3-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@wiregate.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben


gbglace
Reactions:
Beiträge: 1619
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 577 Mal
Danksagung erhalten: 576 Mal

#64

Beitrag von gbglace »

Hi Stefan,

Danke für den Entwicklungseinblick zum DMX. Ja das mit der Wartezeit kann ich bestätigen. Da sich bei mir im Haus dieses Jahr einiges in Richtung fertig bewegt, bin ich ja noch der Hoffnung erlegen zum Herbst wenigstens so ein feines Stückchen DMX-Controller-HW hier zu haben. Mit Alpha/Beta Software hab ich dann kein Problem. Mein Ziel ist halt Mal mehr von den vielen Lichtkreisen bei mir differenziert nutzen zu können. Umwege über das neue kleine Weinzierl-GW will ich ja auch vermeiden.
Grüße
Göran

-- --Timberwolf 2600 Velvet Red-- -- TWS #225 / VPN aktiv / Reboot OK


Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 4153
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 1836 Mal
Danksagung erhalten: 3200 Mal
Kontaktdaten:

#65

Beitrag von StefanW »

Hallo Göran,
gbglace hat geschrieben:
Fr Mai 08, 2020 6:56 pm
bin ich ja noch der Hoffnung erlegen zum Herbst wenigstens so ein feines Stückchen DMX-Controller-HW hier zu haben.
Ansich fehlt da nicht mehr viel. Es ist eigentlich nur die Verwaltung der DMX Extensions und deren Einbindung in das Objektsystem.

Da wir solchermaßen derzeit ganz viel machen (ekey Controller, KNX Schnittstellen und derzeit die "MODBUS Isolated DUAL RTU" Extensions) ist das gut geübt, das Design der Oberfläche steht auch und es sollte kein großer Akt mehr sein. Alles andere zu DMX ist bereits fertig zur Nutzung der virtuellen Dimmer in der LogikEngine.

Die Produktion der DMX Controller ist ebenfalls keine große Sache, womöglich legen wir das gleich gemeinsam mit den MODBUS Extentions auf, weil 85% der Bauteile gleich sind und dann muss man die Maschine nur einmal einrüsten.

gbglace hat geschrieben:
Fr Mai 08, 2020 6:56 pm
Mit Alpha/Beta Software hab ich dann kein Problem.
Soviel Alpha und Beta ist es dann gar nicht mehr, weil ja das meiste schon bei den Hutschienenmodellen seit einem dreiviertel Jahr läuft - ohne eine einzige negative Rückmeldung.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@wiregate.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben


Izeman
Reactions:
Beiträge: 98
Registriert: So Aug 12, 2018 9:03 pm
Hat sich bedankt: 17 Mal
Danksagung erhalten: 27 Mal

#66

Beitrag von Izeman »

Hallo Stefan,

bei mir warten auch noch 100 DMX-Kanäle darauf an den Timberwolf angeschlossen zu werden.

Ich bin jemand der dich dafür liebt wenn dir mal was rausrutscht :-)
Vielen Dank für den tollen Einblick in euer DMX-Entwicklungslabor.

Lieben Gruß Bernd
wiregate 386, timberwolf 222 (2600er), Professional Busmaster 221, VPN offen, Reboot gerne


Robert_Mini
Reactions:
Beiträge: 2371
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 592 Mal
Danksagung erhalten: 1070 Mal

#67

Beitrag von Robert_Mini »

Hallo Stefan!

Danke für die wie immer spannenden Einblicke.

Zurück zur IP2:
Mein TWS zeigt ein RAM-Auslastung von 98%. Auffällig ist der timeseries-DB Prozess mit 0,9GB RAM-Verbrauch.

Wollt ihr da draufschauen oder soll ich den Prozess einfach mal neustarten?
Edit:
Ich habe jetzt mit dem Abschicken des Postings 1 Tag zugewartet, das Bild ist das gleiche. Die RAM Anzeige liegt noch bei 97/98% (und hat einen roten Smiley zur Folge), der RAM Bedarf des timseries-DB liegt noch immer bei 0,56GB.

Ich kann sonst kein Problem erkennen und habe nichts geändert (außer das Update und ein wenig an Logiken getüfftelt).

Wie sieht man eigentlich, wieviel RAM die Container ziehen?

lg
Robert
RAM.png
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / Wiregate-Fan


ms20de
Elaborated Networks
Reactions:
Beiträge: 351
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 147 Mal
Danksagung erhalten: 198 Mal

#68

Beitrag von ms20de »

Robert_Mini hat geschrieben:
Sa Mai 09, 2020 1:19 pm
Wie sieht man eigentlich, wieviel RAM die Container ziehen?
Aktuell nur im Protainer unter "Stats":
portainer_statistics.png
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage


Sun1453
Reactions:
Beiträge: 683
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 441 Mal
Danksagung erhalten: 304 Mal

#69

Beitrag von Sun1453 »

Hallo Stefan,

auch von mir Danke für die tiefgreifenden Informationen aus dem Bereich DMX.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache


ms20de
Elaborated Networks
Reactions:
Beiträge: 351
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 147 Mal
Danksagung erhalten: 198 Mal

#70

Beitrag von ms20de »

Robert_Mini hat geschrieben:
Sa Mai 09, 2020 1:19 pm
Zurück zur IP2:
Mein TWS zeigt ein RAM-Auslastung von 98%. Auffällig ist der timeseries-DB Prozess mit 0,9GB RAM-Verbrauch.
Hallo Robert,

wir haben nichts an der TimeseriesDB geändert, woraus sich ein erhöhter RAM-Verbrauch erklären würde.

Du hast 220 Timeseries und in der Logik einige Doktor-Modi aktiv, man kann also nicht sagen die Datenbank ruhend.
Es ist nicht ausgeschlossen, dass es auch mit diesem Thema zusammen hängt, da du 1.5 GB Logik Scope Daten hast.
viewtopic.php?f=24&t=2149

Wegen der RAM Auslastung und dem roten Smiley, hast du dir schon mal deinen OpenHAB Container angesehen?
Hier werden 2,4 GB RAM benötigt, laut Portainer.
Vielleicht kannst du dir das hier mal ansehen, da hat jemand auch ein Problem dass OpenHAB allen seinen RAM verbraucht:
https://community.openhab.org/t/openhab ... swap/63394

OpenHAB_Memory_Usage.png
Viele Grüße,
Matthias
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von ms20de am Mo Mai 11, 2020 11:40 am, insgesamt 2-mal geändert.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

Antworten

Zurück zu „Bekanntmachungen“