Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
could work. haven't tried yet. But let us know if it works. May be usefull to others.
Got the first cheap RS-485 USB adapter today ( I ordered several different types) and can report that it worked wonderfully. I have not installed "mbusd" in Edomi as I am running this on a virtualized server, but it should also work there without any problems.
So a €1 adapter together with some software can do the job wonderfully.
hardware for what? energy measuring or modbusRTU to modbusTCP converter, temperatures....
What type of application do you mean.
I use this LBS for getting values from UPS Systems for example.
Sorry, I mean hardware for converting from modbusRTU to use with this LBS in Edomi.
I want to use it with a Systemair ventilation system to get temperatures, fan speeds, etc.
hardware for what? energy measuring or modbusRTU to modbusTCP converter, temperatures....
What type of application do you mean.
I use this LBS for getting values from UPS Systems for example.
Meine Gedanken gehen in eine ähnlich Richtung (der LBS hier war mein Erstlingswerk und heute würde ich einige Sachen anders machen...).
Allerdings nicht per CSV sonder eventuel als String Tuple pro Eingang oder JSON Konstrukt.
String-Tuple für die Adressen finde ich gut. Dann optional entweder den Pfad zu einer CSV (die zur Adresse Beschreibungstext, Einheit, Format und Umrechnung liefert) oder in einem anderen Eingang als String-Tupel die entsprechenden Parameter in der Reihenfolge der zuvor angegebenen Adressen. Dann hat man beide Optionen.
Ausgabe als JSON scheint mir wunderbar universell und gut nutzbar, ob mit 1, 5 oder 15 Werten.
1.) Ist es eigentlich schonender, statt 5x eine Adresse mit kurzer Länge zu lesen, lieber 1x den gesamten Bereich lang zu lesen und sich dann die relevanten Teile heraus zu schneiden? Man müsste nur die größe und kleinste Adresse (+ Länge der größten Adresse) als Intervall nehmen und würde damit nur 1x lesen für alle Adressen.
Das halte ich für keine gute Idee, da das zwar in der Theorie so gehen sollet aber in der Praxis eben nicht. (Hast du oben ja selbst schon gemetkt als du ein Register zu "kurz" gelesen hast. Heute werden Register Addresse un Länge eher als Synonym für eine Variable genutzt und so sollte man Sie auch benutzten.
Allerdings möchte ich eben die Lage etwas entspannen in dem ich nur eine Verbindung aufbaue und diese dann immer weiter benutze.
2.) Auf der oben verlinkten GitHub-Seite finde ich den Ansatz ganz chamant, pro Gerät eine CSV mit den Beschreibungstext, Einheit und Format zu haben. Dann braucht man beim Aufruf nur noch die Liste der Adressen und den Pfad zur richtigen Datei und mehr nicht. Ich habe z.B. drei verschiedenen SMA-Geräte, die jeweils von SMA eine unterschiedliche CSV brauchen (die SMA liefert oder man sich selber bastelt). Das ganze könnte ja auch optional sein; ohne Datei müsste man weiterhin die Formate angeben. Andere Hersteller liefern ja sicher auch ähnliche Infos. Die kämen halt in die spezifischen Ordner, wo ggf. auch die spezifischen Bibliotheken liegen.
Meine Gedanken gehen in eine ähnlich Richtung (der LBS hier war mein Erstlingswerk und heute würde ich einige Sachen anders machen...).
Allerdings nicht per CSV sonder eventuel als String Tuple pro Eingang oder JSON Konstrukt.
3.) Gerade mit einer Datei wäre es vielleicht noch generischer, wenn man statt 5 festen Adressen eine Liste von x Adressen (komma-getrennt) übergeben würde und der LBS liefert dann ein JSON zurück als Ausgabe. Dahinter kann man dann wunderbar aus dem JSON die Daten in KOs extrahieren. Oder ist das unnötig aufwändig im Logik-Editor und die direkte Aufbereitung (wie derzeit) ist sinnvoller?
Das ist ziemlich genau auch was ich mir gedacht habe.
Einen Punkt den man auch noch beachten muss ist ob das Gerät "ModBus TCP" oder "ModBus RTU over TCP" spricht, ist leider ein kleiner Unterschied.
Ersters ist normalerweise bei Geräten die schon eine Ethernetschnittstelle für ModBus haben letzteres für ältere Geräte die "nur" RS484 sprechen und über einen Wandler auf TCP gewandelt werden.
mit endianess = 1 fehlte mir mit Deiner Bibliothek dennoch die "65", es muss da also vermutlich noch mehr Anpassungen in den Bibliotheken geben.
Habe das nicht weiter erforscht, sondern jetzt einfach mal so hingenommen, dass man vielleicht verschiedene Bibliotheken braucht... Ist ja auch nur eine Eingang mehr im LBS und bringt hohe Flexibilität für Hersteller-Eigenheiten. Aber was eigenes ...naja...da hat man halt was eigenes...so ganz nach Loriot...
Hast Du denn schon bei Dir intern eine neue Version des LBS ohne Bibliothek und mit dauerhaftem connect?
Nachtrag: Ein Brainstorming zum Thema (mag also Unsinn dabei sein...) - und bitte nicht falsch verstehen, ist keine Kritik am bestehenden Baustein...nur eine Ideensammlung:
1.) Ist es eigentlich schonender, statt 5x eine Adresse mit kurzer Länge zu lesen, lieber 1x den gesamten Bereich lang zu lesen und sich dann die relevanten Teile heraus zu schneiden? Man müsste nur die größe und kleinste Adresse (+ Länge der größten Adresse) als Intervall nehmen und würde damit nur 1x lesen für alle Adressen.
2.) Auf der oben verlinkten GitHub-Seite finde ich den Ansatz ganz chamant, pro Gerät eine CSV mit den Beschreibungstext, Einheit und Format zu haben. Dann braucht man beim Aufruf nur noch die Liste der Adressen und den Pfad zur richtigen Datei und mehr nicht. Ich habe z.B. drei verschiedenen SMA-Geräte, die jeweils von SMA eine unterschiedliche CSV brauchen (die SMA liefert oder man sich selber bastelt). Das ganze könnte ja auch optional sein; ohne Datei müsste man weiterhin die Formate angeben. Andere Hersteller liefern ja sicher auch ähnliche Infos. Die kämen halt in die spezifischen Ordner, wo ggf. auch die spezifischen Bibliotheken liegen.
3.) Gerade mit einer Datei wäre es vielleicht noch generischer, wenn man statt 5 festen Adressen eine Liste von x Adressen (komma-getrennt) übergeben würde und der LBS liefert dann ein JSON zurück als Ausgabe. Dahinter kann man dann wunderbar aus dem JSON die Daten in KOs extrahieren. Oder ist das unnötig aufwändig im Logik-Editor und die direkte Aufbereitung (wie derzeit) ist sinnvoller?
Zuletzt geändert von saegefisch; 19.01.2018, 18:16.
Die Endianess kannst du auch in meinem LBS schon umstellen, du must nur die Variable in Baustein umstellen.
Ich hab dafür leider einen Eingang genommen da das normalerweise nicht ständig geändert werden muss.
Hab ich vielleicht auch vergessen in die Hilfe zu schreiben
von PHPModbus bin ich generel abgekommen da diese Lib leider pro Request eine Connection aufbaut und das zumindest bei mir abundzu irgendetwas aus dem tritt bringt.
Da Modbus eigentlich ziemlich simpel ist werd ich es wohl selber bauen.
Da schwierigeste ist sowieso die Konvertierung der Datentypen und die sollte schon recht zuverlässig klappen.
Neue Infos nach ein wenig Suche zum Thema: Für SMA scheint man besser eine andere ModBus-Bibilothek zu nutzen (Zitat; siehe Link: "SMA uses a different endianess as usual. Also the recv()-Routine needed to be modified.").
Ich habe mir jetzt einfach mal unter /usr/local/edomi/main/include/php jeweils einen Ordner modbus mit der Bibliothek von Dir und einen Ordner modbus_smaaus dieser GitHub-Quelle (bzw. dort verlinkt) parallel abgelegt. Wenn ich im Test-PHP die an SMA angepasste Bibliothek nehme, kommt mein fehlende "65" (s.o.) wunderbar.
Es wäre daher für einen generischen ModBus-LBS in einer bunten Welt von ModBus-Interpretationen von Herstellern sicher zweckdienlich, wenn man x ModBus-"Geschmacksrichtungen" parallel ablegen kann und im LBS den jeweils passenden (ganzen) Pfad oder einfacher vielleicht nur das Unterverzeichnis der gewünschten Bibliothek wählen kann.
Man muss manches Rad ja nicht noch einmal erfinden, wenn andere bereits eine Erfahrung machten und daraus eine Bibliothek strickten...
Der Aufruf mit 30050 und 30052 ergab stets Fehler, daher scheinen die Angaben aus der SMA-Doku schon zu passen. Auch eine Länge von 3 führte zu einem Fehler. Daher bleibt das ausbleiben des 4. Werts druchaus gerade ein Rätsel für mich.
Wegen Interesse: Auf jeden Fall. Denn als Autor des LBA 19000110 sieht die Lage derzeit so aus: Damit wollte ich dauerhaft mir Daten aus dem WebPortal lesen in edomi ablegen für Diagramme, etc. Das hat auch lange produktiv bei mir funktioniert. Leider Hat SMA (zumidnest sieht es für mich so aus) die Anzahl der täglichen Zugriffe Zug um Zug reduziert und/oder die Dauer, in der das Abholen ununterbrochen funktioniert. Selbst wenn ich auf 5-minütlich gehe, hört der Nutzen des LBS Nachmittag soder frühen Abend auf - da die Quelle bis 0:00 Uhr zu macht. Daher scheint mir derzeit mein LBS für das Sunny Portal nur noch zweckdienlich für gelegentliche (und dann aber auch in sehr hoher Frequenz möglichen) Abholung, wenn man auf der entsprechenden Visu-Seite ist.
Lange Rede, kurzer Sinn: MIt ModBus kann ich endlich and die Werte meiner SMA-Anlage ohne die SMA-Cloud und ohne, dass sie mein Haus verlassen. Ich habe daher großes Interesse an einer ModBus-Lösung! Damit kann ich mir meine Datenbasis für Diegramme bauen, die ich möchte.
Dies gilt vermutlich für die meisten PV-Betreiber, mindestens von SMA. Da ich generische Lösung immer wunderbar finde: Gerne, ich unterstütze auch mit Wissen und Test.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: