Irgendwie vermisse ich die alte FS20-Tester-Funktion im System.
Dass es da im Downloadbereich einen separaten FS20-Tester gibt, ist mir wohl bekannt. Nachteil von dem Teil ist jedoch, dass zu dessen Nutzung immer erst eine FHZ frei sein und diesem zugewiesen sein muß. (falls ich das mißverstanden haben sollte, bin ich für jeden hilfreichen Hinweis dankbar)
Bei mehreren FHZ, im „lebenden System“ im „Gelände verteilt“, wird das manchmal etwas abenteuerlich, um schnell mal Tests durchzuführen. Wenn das ohne lange und potentiell auch noch fehlerträchtige Aktionen (richtig zurück zugewiesen?) getan werden könnte, wäre das sehr hilfreich.
Zu den Tests gehört m.E. nicht nur, die gerade aktive Adresse angezeigt zu bekommen, sondern auch, welche FHZ’s alle diese empfingen, also welche Empfänger geographisch / funktechnisch im Empfangsbereich des Sensors lagen. Besonders, da anders als in V1 in V2.x ja nicht mehrere IO-Module einem Splitter o.ä. zugeordnet werden können, sondern explizit doppelte/mehrfache Empfangs-Strukturen aufgebaut werden müssen, um auch bei „schlechtem Funkwetter“ einigermaßen stabile Bedingungen zu haben, sind immer wieder mal schnelle Tests erforderlich. Das Umgestecke / Umweisen ist da einfach zu umständlich.
Mein Vorschlag:
Die FS20-Tester-Funktionalität ins aktive System z.B. als „weitere Ansicht“ integrieren, wobei diese sofort die FHZ-Instanzen des aktiven IPS-Systems nutzt.
…und die Königsklasse (und gegenüber V1 wirklich eine Weiterentwicklung) wäre es, wenn das nicht nur mit den FHZ ginge, sondern z.B. auch mit den HM-Adaptern usw., also vielleicht allen IO-Instanzen? Also statt „FS20-Tester“ ein Schritt in Richtung systeminterner Signal-Debugger / -tracer / -scanner?
Bevor da jemand meckert: Natürlich kenne ich auch die „Debug“-Funktion an den Instanzen. Aber die zeigt ja eben immer nur die Daten genau dieser einen Instanz an, an der sie gestartet wurde, und nicht die Signale aller Empfänger des gleichen Typs. Hier eine entsprechende Erweiterung einzubauen (Checkbox-Schalter „zeige Daten aller xxx-Empfänger an“), wäre natürlich auch ein denkbarer Weg. Ebenso, wie es ja sicher nicht schwer sein dürfte, die „Suchen“-Ausgaben der Adresszuweisungen (enOcean, HMS100 usw) hier zu verwenden, was auch gleich Hinweise auf bestehende Zuweisungen und Verwendungen der Signale/Adressen geben würde.
Vielleicht ist der Aufwand gar nicht so groß, wenn man diese „Fertigbauteile“ verwenden könnte, sondern müßte nur mal eigenständig zusammengefaßt und bzgl. anzuzeigender Werte anders zusammengewürfelt und eingebunden werden?
Um das mal gedanklich weiterzuentwickeln:
Als wirklicher Debugger würde das natürlich in nächster Stufe mit Debugger-typischen Komponenten gut ergänzbar sein, also Filter (Adressbereiche, zu berücksichtigende Instanzen (Sensoren als auch Empfänger), eigenes Logging…), aber auch Schwellwert-Trigger, sozusagen als „Breakpoint“, wobei auch hier eigentlich übers IPS verteilt alles schon da ist. Zu ergänzen wären vielleicht Signalstärken-Ausgaben und -Schwellwerttrigger (z.B. die RSSI-Daten an Homematic auswertend?)
Als typische Trace-Funktionen würde dann darauf wiederum ein „Signalverfolgen“ und „Einzelschritt-Weiterschalten“ aufsetzen können, sprich: Logs bzw. Screen-Ausgaben, die Info geben über nachgeschaltete Ziele und z.B. Variablen-Trigger usw. bzw. wo die Signal-Weitergabe an Breakpoints/Triggern gestoppt und im „Einzelschritt“ beobachtend (Ausgabe am Debug-Screen) weitergeschaltet werden könnte.
Das wäre dann wirklich ein Schritt zu einer angemessenen und irgendwie dem ja ziemlich mächtig gewordenen Grundsystem entsprechenden Entwicklungs-Unterstützung, oder?
Ok, soweit zur Science fiction (obwohl das in keinster Weise neu ist und wir sowas schon in den frühen 90ern an den Z80-Entwicklungsumgebungen hatten, neu wären die Prozess- und Signal-Steps). Sorry, da ging wohl der Funktechniker und PRocess-ITler mit mir durch :rolleyes:
…aber fürs Erste wär ich schon froh, wenigstens die alte V1-FS20-Tester-Funktion hier inline(!!) nutzen zu können.
Gruß Gerd