[TIPP] MODBUS PROFIL: SunSpec Modbus Implementierung für PV-Wechselrichter (z.B. Solaredge,...)

[StefanW]

Hallo zusammen,

wir haben nun den Mathebaustein fertig und sind dabei diesen zu integrieren. Wenn alles klappt, wird dieser in der nächsten Insider Version enthalten sein.

Stefan

[StefanW]

Hallo,

hier noch ein Bild vom neuen Mathebaustein in Aktion mit genau dem hier beschriebenen Anwendungsfall (im Doktormodus)

2021-04-19_Mathebaustein_DocMode.jpg

Bitte beachten: Es gibt hier auch einen Errorausgang, hierüber kann man ein boolsches Objekt erhalten, ob die Berechnung ausgeführt werden konnte.

==> Wurde heute den Dev-Testern zur Verfügung gestellt


lg

Stefan

[tger977]

so, Profil ist angepasst, der Mathebaustein eingerichtet, jetzt fehlt nur die Sonne zum testen...

Ich schau morgen mal ob es funzt, bin aber guter Dinge!

Danke an Elabnet für die Umsetzung des Mathebausteins.

[tger977]

zumindest das Modbusprofil sollte nun hoffentlich passen. Es sind nun keine Umrechnungen mehr drin, da man ja leider sich immer selbst den physikalischen float Wert aus dem INT Register und dem Scalefactor dynamisch zusammenbauen muss. Das funktioniert dann mit dem neuen Mathebaustein mit dem TW. INT und SINT habe ich nun auch nochmal überprüft/angepasst und sollte jetzt passen.

modbus-timberwolf-product-440-13.json

Ich muss nur gerade noch etwas mit den Triggern experimentieren. Da derzeit noch alles ziemlich ungefiltert über den KNX Bus rauscht ist da grad etwas zu viel los. Leider gibt es am Ausgang des Mathebausteins keine Funktion um das Senden dort zu "kontrollieren" (das ist ja im Modbusteil eigentlich vorgesehen mit Zeit/Wertänderungstrigger). Aber da muss ich noch etwas drüber nachdenken wie ich das nun für mich sauber löse daß nicht zuviel KNX Traffic+riesige (und auch unnötige) Datenmengen in den timeseries landen...

[StefanW]

Hallo Andi,

das Zauberwort bei den Abfragegruppen sind die Sendefilter, die kann man sicher gut so einstellen, dass weniger an den KNX gesendet wird.

Vorschlag:

1. Abfragen so weit das von den Modbus Geräten ermöglicht wird (also alle paar Sekunden)
2. Sendefilter für Wertänderung auf eine Handvoll Prozent (je nachdem wie schnell sich was ändert)
3. Zusätzlichen Sendefilter auf 10 Minuten, damit regelmäßig ein Update kommt

Man kann den Ausgang des Mathebausteins auch über einen weiteren Baustein mit Sendefilter geben

Man kann den Traffic am KNX auch dadurch reduzieren, indem man mit einer zweiten Abfragegruppe mit größeren Intervallen nur dafür arbeitet

lg

Stefan

[tger977]

Hallo Stefan,

danke, zufällig habe ich ziemlich genau diese Filter schon so aktiviert und das hilft schon mal enorm die Buslast zu reduzieren!

Aber jetzt ist mir gerade noch aufgefallen, daß es noch zu einem Sprung in der Timeseries kommt wenn die Scalefactors sich ändern. Da scheint noch was in der Abrufreihenfolge bzw. ggf. auch mit den Triggern im Mathebaustein schief zu sein.

Ich habe folgende Modbus Abfrage im Gerätemanager erstellt:

Modbus1.PNG

Hier habe ich extra die Exklusivität angehakt um sicherzustellen daß die ausgelesenen "Datenpärchen" immer konsistent sind.

Im ersten Schritt vor Aktivierung der SendeFilter hatte ich zuerst dort immer alle Werte weitergeleitet (sprich keinerlei Sendefilter!) um sicher zu sein daß wenn der INT Wert gelesen wurde auf jeden Fall auch der passende Scalefactor bereits gelesen wurde und den Mathebaustein habe ich dann entsprechend so konfiguriert daß immer bei Änderung des INT Wertes getriggert wird (da ja vor dem INT Wert per Modbus der Scalefactor gelesen wurde sollte das dann konsistent sein):

Logik1.PNG

Nach Aktivierung der Sendefilter habe ich aber bei Änderung der Scalefactors jetzt kurze 10er Potenzsprünge in der timeseries, d.h. INT und Scalefactor waren offensichtlich doch kurz inkonsistent.

Lange Rede kurzer Sinn: Wie muss ich das aus eurer Sicht einstellen daß immer konsistente phy. Werte im Mathebaustein rauskommen, aber auch nicht am Mathebaustein Ausgang immer alles alle 5s auf den Bus gesendet wird?

EDIT: Aus meiner Sicht wäre es da hilfreich den zweiten (INT) Wert abhängig von der Wertänderung des erst gelesenen Scalefactors zusätzlich triggern zu können (eigentlich dachte ich daß der INT aufgrund des 1% Sendefilter auch upgedatet werden sollte bei einer Scalefactoränderung). Oder ist das Problem beim Mathebaustein zu suchen (Rechenreihenfolge,...)?

[tger977]

ich sehe gerade in meinem eigenen Screenshot oben, daß der gelesene Scalefactor vom Modbus -1 war, im letzten gesendeten Ergebnis aber eine -2 drinsteht. Wie kann das sein? Der Sendefilter >1 hätte da doch den Wert -1 durchschicken sollen, oder?

[StefanW]

Hi Andi,

Matthias wird sich das ansehen, womöglich trennen wir das auch ab und behandeln das im Dev-Unter-Forum, weil es ist ein DEV-Softwarestand (also mehr Alpha als Beta)

Edit: Nur kurze Idee: Eine Änderung von -1 auf -2 ist eine Änderung um -1. Ein Filter "GRÖßER 1" würde das nicht erfassen, da die Änderung 1 ist nicht >1. Probiere mal "> 0.99".

lg

Stefan

[tger977]

oh ja, ich schau da ehrlich gesagt gar nicht genau drauf was in welchem Forenteil ist und lese/antworte einfach immer nur auf die neuen Beiträge... Könnt ihr gerne abtrennen, ich poste dann halt nochmal die "Lösung" wenn wir Sie dann haben.

Und danke daß Matthias das morgen ansieht.

[tger977]

Edit: Nur kurze Idee: Eine Änderung von -1 auf -2 ist eine Änderung um -1. Ein Filter "GRÖßER 1" würde das nicht erfassen, da die Änderung 1 ist nicht >1. Probiere mal "> 0.99".

Autsch, da hätte ich auch selbst drauf kommen können . Hab es eben mal geändert, leider ist nun schon wieder die Sonne weg. Morgen geht's weiter...