Genau. Die 60 Sekunden werden exakt an der Variable getrackt. D.h. wenn zufällig die Hälfte der Variablen mal geändert wurden, dann ändert sich die hälfte so und die andere hälfte später. Das war übrigens die Logik, die schon in der alten „ModBus Adress“ Instanz so war 
Kommt wie gesagt aus unseren Industrieanwendungen, die nicht alle 100ms ein „Ping“ in der Visu wollen und unnötig Last auf allen Seiten erzeugen.
paresy
Ah, alles klar. Danke für die Erklärung!
Ansonsten ein Traum. Ich aktualisiere gerade 60 Variablen auf einen Schlag und das ohne einen einzigen Fehler, selbst ohne die neue Option, die Fehler zu unterdrücken. Und die virtuellen werden auch noch mitgezogen. 
Was lange währt wird jetzt endlich gut
Danke für eure Geduld!
paresy
Mir ist da beim Testen übrigens noch eine Verbesserungsidee gekommen (ohne die Erwartung, dass das kurzfristig umgesetzt wird). Zur 11.0 reicht völlig… 
Im Moment ist es so, dass ich für die Berechnung der virtuellen Adressen zunächst die realen Adressen abfragen und als Variable speichern muss.
In vielen Fällen interssiert mich der Inhalt der realen Adressen aber gar nicht wirklich. Das ist zum Beispiel dann der Fall, wenn der Scaling Factor über ein eigenes Register geliefert wird. Dann lese ich beispielsweise die Adresse mit dem relevanten Wert, die Adresse mit dem Scaling Factor und berechne aus beiden eine virtuelle Adresse, mit der ich arbeite. Die anderen beiden Adressen und deren Variablen sind eigentlich nur Abfallprodukte.
In solchen Fällen wäre es aus meiner Sicht schön, wenn man die “Hilfsadressen” erst gar nicht als Variable speichern müsste. Dass man sie in der Instanz konfiguriert, um sie auszulesen ok, aber der Wert muss ja deshalb nicht zwingend in eine Status-Variable geschrieben werden. Es wäre doch ausreichend, wenn man die Register einfach nur ausliest und die Werte dann intern speichert, um sie für die virtuellen Adressen heranzuziehen. Man bräuchte also neben der Möglichkeit eine Adresse aktiv zu schalten auch eine Option, mit der man festlegen kann, ob eine Status-Variable angelegt werden soll oder nicht.
Wenn ich in der derzeitigen Implementierung hergehe und die realen Adressen deaktiviere, dann bekomme ich auch keine Akualisierungen für die virtuellen Adressen mehr, selbst dann nicht, wenn die Adressen im Hintgerund per Blockabfrage gelesen werden.
Das Thema passt vielleicht auch ganz gut zur aktuellen Variablen-Diskussion in Bezug auf die neuen Lizenzmodelle. Man würde sich dadurch überflüssige Variablen sparen und der Performance wäre es sicher auch zuträglich, wenn man auf unnötige Variablenaktualisierungen verzichten kann.
Ich finde die Idee gut (nervt mich auch) - ich muss aber mal schauen, wie wir dies gut umgesetzt bekommen. Am schönsten wäre ja, wenn man die „deaktivieren“ kann aber in der virtuellen Adresse doch als „benötigt“ deklarieren kann.
paresy
Drei spontane Ideen.
Im Moment werden die Adressen/Variablen ja alle über ihren Ident angesprochen. Man könnte einen Automatismus bauen, der vor dem Abfragen prüft, welche Idents in den virtuellen Adressen angesprochen werden. Dann könnte man alle Adressen mit diesem Ident abfragen, unabhängig davon, ob sie aktiv sind oder nicht. Wenn sie inaktiv sind, nutzt man die Daten halt nur intern. Würde im Übrigen die Fehlermeldungen verhindern, die aktuell kommen, wenn man benötigte Variablen deaktiviert. Allerdings muss man dafür natürlich alle Skript-Schnipsel nach den Idents durchsuchen, was vielleicht auch nicht so toll ist.
Man könnte die benötigten Variablen in der virtuellen Adresse separat als Liste oder ähnliches hinterlegen. Würde natürlich den Konfigurationsaufwand erhöhen und zu Lasten der Übersichtlichkeit gehen.
Oder einfach ein zusätzliches Attribut je Adresse (Checkbox), ob die Status-Variable erzeugt werden soll. Man könnte benötgite Adresen dann zwar immer noch deaktivieren und es käme zu einem Fehler, aber das wäre aus meiner Sicht eine relativ einfach zu implementierende Lösung und dennoch übersichtlich.
Vielleicht fällt mir bis zur 11.0 ja noch was besseres ein. 
Sorry, falls ich nerve, aber wir sind ja noch bei den Testversionen / RCs.
Folgendes ist mir noch aufgefallen:
Beim Import der Vorlagen werden die Einstellungen zur Blockabfrage nicht importiert. Diese sind zwar in der Vorlage enthalten, es wird jedoch nur der Abfragetyp gesetzt. Die einzelnen Blöcke werden nicht importiert.
Wenn ich die Vorlage lade und diese eine Blockabfrage beinhaltet, erscheint nach dem Laden nicht der Button zur Konfiguration der Blöcke. Dieser taucht erst auf, wenn man das Formular einmal speichert, ist dann aber leer (siehe 1).
Die Fehlerbehandlungsmethode ist nicht Teil der Vorlage. Sie ist auch gar nicht im Export-File enthalten, wenn ich es richtig sehe. Keine Ahnung, ob das Absicht ist.
Wenn Adressen von einer (Geräte-)Instanz abgefragt werden und dieselben Adressen auch in einer anderen (Geräte-)Instanz enthalten sind, werden diese dort nicht mehr aktualisiert, sofern das Gerät sie nicht selbst abfragt. Der Splitter scheint die Daten also nicht mehr an die anderen Instanzen weiterzuleiten oder diese werten sie einfach nicht mehr aus, wenn sie sie nicht selbst abgefragt haben.
Ich weiß nicht, ob das ein Nebeneffekt der neuen Implementierung ist oder ebenfalls ein Bug. Aber theoretisch spricht ja nichts dagegen, dass die anderen Instanzen die Daten trotzdem noch über den Splitter kriegen, wenn sie schon woanders abgefragt werden.
Im Splitter gibt es immer noch die Blockabfrage. Ist das gewollt? Funktioniert die weiterhin? Wenn ja, in Kombination mit den Geräte-Instanzen oder nur für die übrigen Modbus-Instanzen?
Ich wollte das eigentlich hier gepostet haben, falls es sich um einen Bug der neuen Implementierung handelt. Bin aber wohl im falschen Thread gelandet, wie ich gerade gesehen habe.
@paresy hmmm, ich wollte mich nun drum kümmern, dass nun endlich die virtuellen Variabeln funktionieren… ich habe die offizielle 9.0 und wollte nun, wie du wiederum vor ein paar Monaten erwähnt hattest, die Datenblöcke in die Geräte-Instanz übertragen… nur fehlt mir hierzu der entsprechende Button…. weshalb?
Es gibt ein DropDown in dem du umschalten kannst. Von Einzelabfrage auf Datenblöcke. Dann kommt auch der Button.
paresy
Ah, diesen hatte ich übersehen. Und ja, das hat funktioniert. Ich habe umgestellt, dann dort die Datenblöcke erfasst (quasi von den Gateway-Instanzen) und dann haben sich die virtuellen Variabeln tatsächlich aktualisiert das freut mich, dass dies nun doch nach einer ziemlichen Ewigkeit funktioniert! Vielen Danke, das macht das Handling der Variabeln einwenig einfacher.
Aber doch noch eine Frage - was soll ich nun mit den Datenblockabfragen in den Gateway-Instanzen tun? Muss ich etwas ändern resp. welche Einstellungen von den Gateways werden noch benutzt? Abfrageverzörgerung, Wartezeit etc…
Und kann ich die Datenblöcke in den Gateways einfach löschen? Das ist mir nicht ganz klar
Siehe Beispiel bei meiner PV-Abfrage (Wechselrichter) - Gateway:
Und diese Blöcke aus dem Gateway kann ich nun löschen (da bei den Geräte-Instanzen erfasst?)
Danke schon mal…
Genau. Die Timings sind weiterhin relevant. Aber die Datenblock abfragen können im GW raus.
paresy
Alles klar, habe ich nun so gemacht. Danke 
Mir gelingt es nicht, Datenblöcke zu importieren. Hier ein Beispiel:
{
"Addresses": [],
"ByteOrder": 0,
"Profiles": {},
"Requests": {
"DataBlocks": [
{
"Address": 32000,
"Function": 3,
"Poller": 1000,
"Quantity": 6
}
],
"Interval": 5000,
"Type": 1
},
"VirtualAddresses": []
}
Funktioniert das momentan nicht, oder mache ich etwas falsch?
Das ist mir irgendwie durchgerutscht. Fix im nächsten Update.
paresy
Super, das kann ich sehr gut gebrauchen.
Ich bin gerade dabei eine neue Vorlage zu erstellen und da sind es ca. 30 Datenblöcke Da warte ich dann auf den Fix.
Ein anderer Punkt ist die noch fehlende Unterstützung der „neuen“ Darstellung. Da müsste ich über 60 Profile anlegen, das schenke ich mir erst einmal.
Schön wäre es, wenn das Thema auf der Liste zu 9.1 ist
Das ist es
paresy
Super.
Gerade beim Testen fällt mir auf, dass es in der Geräteinstanz keine Möglichkeit gibt, die schreibbaren Statusvariablen zu setzen.
Vielleicht magst du in der Form noch bei den Actions ein Testcenter einfügen
{
"type": "TestCenter"
}
Das macht es einfacher zu testen
Der Fix wirkt Besten Dank!