bei ModBus Geräten ist es noch nicht möglich die neue Variablendarstellung (Vorlagen) auszuwählen. Da gibt es aktuell nur Profile.
um Werte der abgefragten Register zu “filtern” wie z.B. NaN-Werte oder auch andere Berechnungen zu machen, kann man virtuelle Adressen konfigurieren. Das ist schon mal gut. Hat aber den Nachteil, dass man dafür schon mal eine Adresse zur Abfrage des Registers erstellt haben muss. Wenn die “Bearbeitung” nun an sehr vielen Registern erfolgen muss, kommt es hier schon zu einer Verdopplung der benötigten Variablen - wovon man aber nur die Bearbeitete wirklich braucht. Hier wäre es doch besser, wenn man die Bearbeitung (Aktion Lesen, Aktion Schreiben) schon in der Original-Variable machen könnte. Oder wenn das nicht gehen sollte, dass man dann die Original-Variable nur im Modul intern nutzt und nicht im Objektbaum anlegt. Gerade auch im Bezug auf das neue Lizenzmodell und die daraus resultierende Diskussion um benötigte und unnötige Variablen, wäre das eine sinnvolle Anpassung. Bei meinem SMA Wechselrichter z.B. habe ich da schon 10-20 mögliche Register, die so zu bearbeiten sind. Eine nachträgliche Bearbeitung per Skript, würde das Variablenproblem aber auch nicht lösen.
Mit den Darstellungen hast du recht, die sind simpel und einfach da noch nicht implementiert, da müssen wir noch ran. Ist leider nicht die einzige Profil-Baustelle, die noch offen ist…
Ich habe gerade kein Modbus-Gerät parat, aber ich könnte mir vorstellen, dass du die Variable mit dem „Rohwert“ einfach deaktivieren kannst und dann trotzdem den dazugehörigen Wert zur Berechnung einer virtuellen Variable nutzen kannst. Hast du das mal ausprobiert?
die Idee ist nicht schlecht, aber da diese Variable dann nicht mehr erzeugt wird, habe ich auch keinen Ident, den ich bei der Aktion mit $VALUES[] nutzen kann. Dieser wird in der Regel automatisch erzeugt. Aber auch mit selbst definiertem Ident geht es nicht. Sobald ich den “Rohwert” deaktiviere wird er im Objektbaum gelöscht und steht wohl auch modulintern nicht mehr zur Verfügung.
Das Deaktivieren macht hier aber auch Sinn. Wenn Vorlagen verwendet werden, die Register enthalten, die es nicht gibt z.B.
Wenn ihr das Modul vielleicht so anpassen könntet, dass man ein Register nur für “modulintern” definieren kann und es als Quelle für Virtuelle Adressen verwendet. Oder die Funktionalität der Virtuellen Adressen gleich in die Registerabfrage integriert. Wobei beides eine sinnvolle Funktion ist: Ausfiltern von “Fehlerwerten” im Register selbst und z.B. Berechnungen von einem oder mehreren Registerwerten über Virtuelle Adressen.
Kann ich nur unterstützen und hatte ich in einem anderen Modbus-Thread auch schon erwähnt. Ich habe ebenfalls einen Haufen Variablen, die ich eigentlich gar nicht brauche, aber für die virtuellen Variablen trotzdem erstellen muss. Wäre wirklich schön, wenn man intern mit den Registern rechnen könnte, aber am Ende nur eine Variable als Output rauskommt. Ebenfalls wäre es schön, wenn der Splitter Abfragen (normale und Blockabfragen), die von anderen Instanzen kommen, ebenfalls an diese weiterleiten würde, wenn sie dort genutzt werden. Dann würde man sich Mehrfachabfragen sparen.
Ich habe teilweise Blockabfragen über große Bereiche, von denen ich aber nur einen Teil der Register in der abfragenden Instanz benötige. In einer anderen Instanz brauche ich dann Register, die schon in dieser Blockabfrage enthalten sind. Hier wäre es schön, wenn die zweite Instanz die Daten einfach von der ersten mitnehmen würde, sofern die betroffenen Register dort konfiguriert sind. Früher mit dem alten Splitter ging das. In der neuen Konstellation, wo die Logik im Gerät steckt, aber scheinbar nicht mehr. Hier muss ich die betroffenen Register dann erneut abfragen, was die Last auf dem Bus unnötig erhöht.