Guten Morgen Göran,
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 amMerge halte ich nicht für notwendig,
Ja, ich sehe das wie Du.
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 amWarnungen hin oder her da wollen dann viele einfach aus versehen drauf geklickt haben.
Ja, das ist denkbar.
Wir unternehmen mittlerweile für jede neue Produktidee und auch für jedes neue Leistungsmerkmal im Timberwolf Server eine Folgenabschätzung hinsichtlich dem zu erwartenden Aufwand für Support, Dokumentationsumfang, beizulegenden oder anzuzeigenden Warnhinweisen usw. Gut die Hälfte der Vorschläge fällt dieser Folgenabschätzung zum Opfer.
Wir leben mittlerweile in einer Bewertungsgesellschaft. Diese Bewertungen werden eher nicht von professionellen Kritikern auf fachlicher Basis, eingehender Prüfung und mit Ausgewogenheit und Ausgewogenheit getroffen, sondern von jedermann nach eigenem Belieben. Alles was man tut, muss daher so gut wie nur möglich Massenkompatibel sein.
Wir haben das schmerzhaft lernen müssen.
Zum Thema Warnungen selbst:
Wir haben das nun bei der Container Verwaltung gemacht, weil wir annehmen, dass die Kunden das auch akzeptieren. Aber nun bei jedem komplexeren Leistungsmerkmal jeweils einen "Disclaimer mit Bestätigungsanforderung" einzubauen widerspricht der Philosophie eines einfach bedienbaren Produktes.
Beispiel Modbus Implementierung:
Hinsichtlich der Implementierung des Modbus führen wir intern dazu gerade eine Prüfung durch. Bei Modbus betrifft die Normierung nur den Aufbau des Datenpaket für die Kommunikation, also auf der Ebene der Schicht 2 bis 4 nach OSI Modell (es gibt ein paar spezielle Funktionen die tiefer definiert sind).
Format, Bedeutung und Inhalt der eigentlichen Daten ("Payload") ist der jeweiligen Implementierung völlig frei gestellt. Die Hersteller machen dann auch was sie wollen und es ist geradezu atemberaubend, wie diese Informationen codieren, formatieren und teils ineinander verschachteln. Wir haben die Modbus Implementierungen der meisten Anbieter von Modbus Gateways analysiert und keines davon unterstützt diese Vielfalt. Selbst einfache Enumerierungen sind damit nicht auskodierbar, Bitmuster schon gar nicht. Es ist mir ein Rätsel, wie Integratoren damit zum Ergebnis kommen, ich nehme an, dass danach in solchen Fällen noch eine mehr oder weniger komplexe Logik mit Bitshifting usw. erstellt werden muss.
Unser Anspruch an eine Modbus Implementierung ist aber, dass wir eine möglichst große Bandbreite unterstützen werden inklusive einem ausgefeiltem Fehlerhandling. Nur führt solche eine solche (brachiale) Funktionalität zu Komplexitäten, die der Anwender dann auch verstehen muss.
Unsere größte Sorge hinsichtlich "Massenkompatibilität" ist in dieser Sache, dass sicherlich nicht jeder Anwender die gesamte Lernkurve für Modbus nehmen möchte und wir als der Gateway-Anbieter dann die "Schuld" bekommen, dass es womöglich komplex werden kann. Je nachdem wie der Hersteller des Modbus-Gerätes sich das gedacht hat.
Ein Warnhinweis alleine wird womöglich nicht helfen. Deshalb prüfen wir im Moment, dass man dem Editor hinsichtlich des angebotenen Komplexitätsgrades umschalten kann zwischen "Grundfunktionen", "Professionell" und "Experte". Damit sollten wir den Spagat zwischen einfacher Bedienung und komplexeren Leistungsmerkmalen hinbekommen und hoffentlich dann gute Rezensionen erhalten. Einen Disclaimer würde man dann z.B. nur für das Aktivieren der Expertenfunktionen einblenden müssen und hoffen, dass dies dann als "geschickt gemacht" von den Nutzern angenommen wird.
Die beiden Parameter "Usability" und "Acceptance" sind heutezutage eine sehr große Herausforderung, insbesondere für ein mittelständisches Unternehmen, das sich dafür nicht eine eigene Abteilung, spezielle Agenturen und Marktforschung leisten kann. Da kann ein Fehlgriff im Design schnell das Aus bedeuten. Es ist eine sehr große Herausforderung, mit den hohen technischen Standards der Konzerne mitzuhalten.
==> Würde mich interessieren, wie Ihr über solche Modusumschaltungen "Anfänger" zu "Experten" für manche komplexe Funktionen denkt, weil das wäre auch bei diesem Thema denkbar, dass solche komplexeren Funktionen ersteinmal hinter einer "Schranke" versteckt sind.
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 amDann einfach x TS downloaden in geeigneten eigenen Werkzeugen wie gewünscht mergen und dann in eine neue hochladen, nicht benötigte alte TS einfach auf dem TWS löschen. fertig.
Richtig, sehe ich auch so.
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 ameinen automatischen sauberen Merge zu unterstützen ist schon sehr aufwändig.
Und womöglich gar nicht von der Datenbank unterstützt bzw. nicht zielführend.
Beispiel: Nehmen wir einen Sensor dessen Daten im Schnitt alle 5 Minuten aufgezeichnet werden. Das ergibt für ein Jahr dann 105.000 Datenpunkte die nach Möglichkeit in wenigen Sekunden in Grafana zur Verfügung stehen sollen. Womöglich mehrere solcher Grafiken gleichzeitig im Dashboard.
Eine Zeitseriendatenbank dürfte sehr davon "leben" dass die Daten schnell und sequentiell hintereinander gelesen werden können. Für aufwendige Indexierungen weil die Daten "kunterbunt" nacheinander zusammengemerged werden besteht womöglich keine Unterstützung im Produkt.
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 amAber im IST und der sonstigen FR-Liste kann ich hierfür keine Dringlichkeiten entdecken.
Ja, würde ich auch meinen.
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 amEs ist eben ein Experten-Feature und als Experte findet man leicht andere Wege die Daten sauber zu mergen.
Jep.
gbglace hat geschrieben: ↑Do Jun 25, 2020 7:27 amDa man ja meist nicht viele Regeln in eine gemeinsame TS schreibt ist auch das notwendige Umhängen dieser Bestandsregeln in eine neue extern erweiterte TS kein Problem und sollte zu keinen großen Datenlücken führen.
Richtig, das geht mit dem DOS Ruckzuck.
lg
Stefan