für den geschäftlich genutzten Teil des Hauses habe ich schon seit vielen Jahren einen DZG DVH 4013 Drehstromzähler in meiner Verteilung, den ich unter Linux mit mbrtu abfrage (mit einem USB RS485 Adapter) und den Wert in den Volkszähler schiebe. Der Volkszähler ist hier seit drei Jahren auf dem Weg "raus", stattdessen benutze ich Grafana auf dem TWS, da war es logisch mal den Timberwolf zum Abfragen des Stromzählers zu benutzen. Da ich den produktiv genutzten Zähler hier nicht anfassen wollte, hat sich anlässlich der ablaufenden Eichfrist des Zählers und dem anstehenden Tausch mit dem Neugerät ein Testfeld ergeben.
Und da hier nächste Woche ein neuer Wechselrichter für die Photovoltaik auftauchen wird, der ("schöne" neue Cloudzeiten) keinen lokalen Webserver mehr haben wird, muss ich sowieso mehr Modbus RTU machen als bisher. Leider haben die Stromzähler andere Kommunikationsparameter (9600 8E2) als der Wechselrichter (9600 8N1, das glaube ich dem Hersteller aber erst wenn ich es sehe), und der Timberwolf 3500 L hat nur noch eine RS485 Schnittstelle. Das bedeutet: ich darf mich auch noch mit einem Modbus RTU zu Modbus TCP Adapter anfreunden.
Und dann werkelt hier auch noch eine Stiebel Eltron LWZ 304 mit einem seit zehn Jahren ungenutzten ISG, das wohl auch ohne den unverschämten Aufpreis für die KNX-Software Modbus TCP sprechen kann.
Das heißt: Modbus wird im Timberwolf für mich wichtig, weil es einfach an vielen Stellen benutzt wird. Gestern habe ich das mal mit dem einen neuen Stromzähler ausprobiert, und ich bin sehr erfreut darüber, wie reibungslos das funktioniert hat. Das ist echt solide, intuitiv benutzbare Arbeit (ich gebe zu dass ich die Doku erst nach dem ersten Erfolg als Nachtlektüre gelesen habe). Ein wenig Feedback:
- Dass ein Modbus-Profil gesperrt wird sobald ein Gerät konfiguriert ist, finde ich lästig. Das bedeutet, dass man für jede Änderung am Profil (was man häufig macht wenn man gerade eins entwickelt) das Gerät komplett entfernen und nach der Änderung am Profil das Gerät mit allen Abfragegruppen neu angelegt werden muss. Das treibt die Turnaroundzeiten echt lästig in die Höhe und ich fände es super, wenn es einen Development Mode gäbe, mit dem man an einem benutzten Modbus-Profil herumprökeln kann. Mir graust es schon davor, wenn ich nach einigen Tagen des Realbetriebs noch Fehler im Profil finde, und dann nicht nur die Abfragegruppen, sondern auch die Zuordnungen im Objektsystem jedes Mal neu setzen darf.
- Aus derselben Kiste kommt der Nerv, dass man ein existierendes Gerät nicht einfach mit einem neuen Profil verbinden kann. Das unterbindet den Workflow "Profil kopieren, Änderung machen, Gerät nachziehen" und führt wieder zur oben erwähnten langen Turnaroundzeit.
- Bei der Erfassung eines Profils funktioniert die Aktivierung der Hex-Eingabe der Werte nicht. Steht in der Doku, ist aber trotzdem lästig. Viele Hersteller geben den einzelnen Bits für in der Registernummer gewisse Bedeutungen, und dass sich 0x4026 nur in wenigen Bits von 0x4046 unterscheidet ist zumindest mir klarer als derselbe Unterschied bei 16422 und 16454 im Dezimalen.
- Das manuelle Eintickern von "nur" 40 Registern für importierte und exportierte Zählerstände (total, L1, L2, L3, import,export, alle Tarife, Tarif 1-4) war eine wirklich stupide Fleißarbeit. Da würde ich mir eine Möglichkeit wünschen ein gewisses Setting für eine Menge selektierter Register in einem Arbeitsgang machen zu können. Mein Glück dass die Register aus meinem Zähler in Wattstunden rauskommen, so musste ich wenigstens nicht 40 mal einen Multiplikator setzen
- Auch die Sperre der Import- und Exportfunktionen finde ich für die Entwicklung lästig. Auch hier wäre ein Development-Modus fein, in dem man ein Profil halt nicht für die Welt exportieren kann, dafür aber flexibler editieren und vor allen Dingen auch solche Dinge wie hunderte fast identische Register einfach aus zehn Zeilen Python oder etwas Excel generieren kann anstelle das stumpf hunderte von Malen einklickern zu müssen. Der Rechner soll Arbeit für mich machen, nicht andersrum.
- In der Anlage der Abfragegruppen gibt das Interface die Trigger für die Weitergabe von Messwerten ins Objektsystem mit "alle Zehn Minuten oder bei Änderungen von > 1 %" vor. Ich habe keine Möglichkeit gefunden hier die Standardwerte zu setzen oder eine bulkänderung für alle drölfzig Zählerregister durchführen zu können. Steht mir da wieder fünfzigfache Handarbeit bevor?
So, und nun nehmt mich auseinander
Grüße
Marc
P.S.: Ich habe mich mit mir selbst geeinigt dass schwArz die A-Ader ist und rot die B-Ader.
P.P.S.: Erfahrungen dieses Artikels mit Timberwolf 3500 L Software 4.0.1
P.P.P.S.: der Link zum Online-Datenblatt aus der Timberwolf-Software führt zu wiki.timberwolf.io/3500 (oder so ähnlich, blitzt nur kurz auf) und redirected dann auf einen 404 von elabnet.atlassian.net
