NEWS
Modbus: Verbindung zu Codesys-Runtime herstellen
-
@minkhx warum willst du mehrere IOB Installationen machen?
Sind die alle an verschiedenen Orten oder geht es nur darum die VIS anzeigen individual zu haben?
Da wäre es aus meiner Sicht auch sinnvoller das Zentral zu machen und einfach verschiedene Projekte anzulegen.
@wendy2702 Hallo Wendy.
Vllt. mal ein Szenario aus einer Heimautomation:
Wenn ioB-Zentrale, was läuft mind. drauf?
Influx, Grafana, Visu. Das Optimieren der Automation über einen Zyklus erscheint mir in diesem Kontext sinnvoll.
Zus. vllt. auch IP-Cams (min. 1080p), die durch die Visu bereitgestellt werden müssten.
Kommen dann noch zeitkontinuierliche Messwertgeber eines Controllers über Modbus rein, dann ists mit einem Pi bald Essig, nehme ich an, für den Fall, dass zB 5 Teilnehmer auf diese Zentrale zugreifen.Vllt. kann man das durch leistungsstarke Hardware (Mini-PC statt Pi) lösen. Schwer einzuschätzen.
Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit.
Oder man nutzt Node-Red (ggü. der DSL könnte man auch in den Bus schreiben)+influx+Grafana mit dem von Peter vorgeschlagenen "node-red-contrib-modbus".
Also entweder an der Hardwareschraube drehen oder die Zentrale ohne den ioB-Overhead nutzen bzw. etwas Ballast abwerfen. Oder beides.Indem man zB die Cam-Stream in dezentrale Pis/Visu einbindet, könnte man die Zentrale deutlich entlasten, denke ich mal.
(Es gibt vllt. auch Tablets, wo man ein Linux flashen kann, aber bleiben wir bei Pi, also Pi+HMI.
Keine Ahnung auf welchen OS ioB sonst noch out-of-the-box lauffähig ist.)
Des Weiteren stünden dezentrale GPIOs zur Verfügung, welche man im Bus zur Verfügung stellt. Keine schlechte Sache.
Auch könnte man pymodbus nutzen. Usw., usw.
Eben ein dezentraler Rechenknecht, der eigenständige Operationen durchführen kann.
ZB ein Remote I/O, aber mit Intelligenz.Wenn man dafür die vis-Lizenz kaufen muss, ist es ja für nen guten Zweck:)
Es gibt viele weitere denkbare Szenarien, wo mind. zwei Hardware-Dinger irgendwas machen und spätestens dann muss man sich von der Zentralisierung lösen.
Modbus bedeutet für mich auch modular.
Nee, das war jetzt Quatsch;)state-of-play (iob<->Codesys per Modbus-TCP):
Mod-Adap. als Client geht fein mit DI/Os. Kommen Register hinzu, werden die bins&coils ignoriert und es funzen nur noch die register.
Ggf. eine Überlappung von Speicherbereichen. Allerdings haben sämtl. Änderungen an den Einstellungen nichts gebracht.
Mod-Adap. als Server funkt wild in der Gegend rum, die Instanz-Objekte bleiben aber gelb und sind daher nicht verwertbar, und ich habe wirklich ALLE 2^6 Einstellmöglichkeiten probiert. -
@wendy2702 Hallo Wendy.
Vllt. mal ein Szenario aus einer Heimautomation:
Wenn ioB-Zentrale, was läuft mind. drauf?
Influx, Grafana, Visu. Das Optimieren der Automation über einen Zyklus erscheint mir in diesem Kontext sinnvoll.
Zus. vllt. auch IP-Cams (min. 1080p), die durch die Visu bereitgestellt werden müssten.
Kommen dann noch zeitkontinuierliche Messwertgeber eines Controllers über Modbus rein, dann ists mit einem Pi bald Essig, nehme ich an, für den Fall, dass zB 5 Teilnehmer auf diese Zentrale zugreifen.Vllt. kann man das durch leistungsstarke Hardware (Mini-PC statt Pi) lösen. Schwer einzuschätzen.
Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit.
Oder man nutzt Node-Red (ggü. der DSL könnte man auch in den Bus schreiben)+influx+Grafana mit dem von Peter vorgeschlagenen "node-red-contrib-modbus".
Also entweder an der Hardwareschraube drehen oder die Zentrale ohne den ioB-Overhead nutzen bzw. etwas Ballast abwerfen. Oder beides.Indem man zB die Cam-Stream in dezentrale Pis/Visu einbindet, könnte man die Zentrale deutlich entlasten, denke ich mal.
(Es gibt vllt. auch Tablets, wo man ein Linux flashen kann, aber bleiben wir bei Pi, also Pi+HMI.
Keine Ahnung auf welchen OS ioB sonst noch out-of-the-box lauffähig ist.)
Des Weiteren stünden dezentrale GPIOs zur Verfügung, welche man im Bus zur Verfügung stellt. Keine schlechte Sache.
Auch könnte man pymodbus nutzen. Usw., usw.
Eben ein dezentraler Rechenknecht, der eigenständige Operationen durchführen kann.
ZB ein Remote I/O, aber mit Intelligenz.Wenn man dafür die vis-Lizenz kaufen muss, ist es ja für nen guten Zweck:)
Es gibt viele weitere denkbare Szenarien, wo mind. zwei Hardware-Dinger irgendwas machen und spätestens dann muss man sich von der Zentralisierung lösen.
Modbus bedeutet für mich auch modular.
Nee, das war jetzt Quatsch;)state-of-play (iob<->Codesys per Modbus-TCP):
Mod-Adap. als Client geht fein mit DI/Os. Kommen Register hinzu, werden die bins&coils ignoriert und es funzen nur noch die register.
Ggf. eine Überlappung von Speicherbereichen. Allerdings haben sämtl. Änderungen an den Einstellungen nichts gebracht.
Mod-Adap. als Server funkt wild in der Gegend rum, die Instanz-Objekte bleiben aber gelb und sind daher nicht verwertbar, und ich habe wirklich ALLE 2^6 Einstellmöglichkeiten probiert.@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
Influx, Grafana, Visu. Das Optimieren der Automation über einen Zyklus erscheint mir in diesem Kontext sinnvoll.
Zus. vllt. auch IP-Cams (min. 1080p), die durch die Visu bereitgestellt werden müssten.
Kommen dann noch zeitkontinuierliche Messwertgeber eines Controllers über Modbus rein, dann ists mit einem Pi bald Essig, nehme ich an, für den Fall, dass zB 5 Teilnehmer auf diese Zentrale zugreifen.Hierfür bietet sich ein Mini PC z.B. NUC oder etwas ähnliches an. Einige viele verwenden darauf dann Proxmox und für die einzelnen Systeme dann LXC (Container) oder VMs. Alles auf einem Rechner Nativ würde ich persönlich nicht empfehlen. Alternativ sind auch einige bei Unraid gelandet.
Nurmal so: bei mir läuft Proxmox auf einem Lüfterlosen PC mit ca. 20Watt Verbrauch im Schnitt und diesen CTs/VMs
Und dieser Auslastung:
Ich greife von 3 Teilnehmern (Jeweils PI5 mit Touchdisplay) zur VIS Anzeige darauf zu.
IP Cams erfordern eh gesonderte Behandlung da die meisten RTSP Streams liefern die so nicht mehr im Browser und damit jeglicher VIS angezeigt werden können. Hier gibt es z.B. Motioneye, AgentDVR, Go2RTC, Frigate und nur einige aufzuzählen.
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit.
Keine Ahnung was du damit meinst.
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
Indem man zB die Cam-Stream in dezentrale Pis/Visu einbindet, könnte man die Zentrale deutlich entlasten, denke ich mal.
Wie bereits geschrieben benötigen die extra Behandlung. Ob und welchen Stream man dann wie und wo in die jeweilige Anzeige einbaut macht bei richtiger Einstellung nicht soviel Prozessor last beim Host aus.
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
(Es gibt vllt. auch Tablets, wo man ein Linux flashen kann, aber bleiben wir bei Pi, also Pi+HMI.
Alle Tablets die mit Android laufen, laufen quasi auf Linux. Dort z.b. den Kiosk Browser nutzen und man kann mit dem Tablet fast alles machen so es denn genug Leistung hat. Alternativ ein Dummes Display oder Touchdisplay wenn denn Bedienung gewünscht ist, PI dahinter der dann "nur" die VIS ANZEIGE macht und fertig. Läuft bei mir z.B. 3mal im Haus.
Wenn du aber eh Rechner verteilen willst würde ich bei iobroker über ein Master / Slave System nachdenken. Ich glaube das würde dir langfristig das ein oder andere ersparen, wie z.B. die Modbus Geschichte mit Codesys.... von der ich immer noch nicht zu 100% verstanden habe warum du das nicht mit iobroker Master - Slave - RPI Adapter umsetzt.
Je nach Rechner könnte man den dann auch parallel zur VIS Anzeige nutzen.
-
@wendy2702 Hallo Wendy.
Vllt. mal ein Szenario aus einer Heimautomation:
Wenn ioB-Zentrale, was läuft mind. drauf?
Influx, Grafana, Visu. Das Optimieren der Automation über einen Zyklus erscheint mir in diesem Kontext sinnvoll.
Zus. vllt. auch IP-Cams (min. 1080p), die durch die Visu bereitgestellt werden müssten.
Kommen dann noch zeitkontinuierliche Messwertgeber eines Controllers über Modbus rein, dann ists mit einem Pi bald Essig, nehme ich an, für den Fall, dass zB 5 Teilnehmer auf diese Zentrale zugreifen.Vllt. kann man das durch leistungsstarke Hardware (Mini-PC statt Pi) lösen. Schwer einzuschätzen.
Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit.
Oder man nutzt Node-Red (ggü. der DSL könnte man auch in den Bus schreiben)+influx+Grafana mit dem von Peter vorgeschlagenen "node-red-contrib-modbus".
Also entweder an der Hardwareschraube drehen oder die Zentrale ohne den ioB-Overhead nutzen bzw. etwas Ballast abwerfen. Oder beides.Indem man zB die Cam-Stream in dezentrale Pis/Visu einbindet, könnte man die Zentrale deutlich entlasten, denke ich mal.
(Es gibt vllt. auch Tablets, wo man ein Linux flashen kann, aber bleiben wir bei Pi, also Pi+HMI.
Keine Ahnung auf welchen OS ioB sonst noch out-of-the-box lauffähig ist.)
Des Weiteren stünden dezentrale GPIOs zur Verfügung, welche man im Bus zur Verfügung stellt. Keine schlechte Sache.
Auch könnte man pymodbus nutzen. Usw., usw.
Eben ein dezentraler Rechenknecht, der eigenständige Operationen durchführen kann.
ZB ein Remote I/O, aber mit Intelligenz.Wenn man dafür die vis-Lizenz kaufen muss, ist es ja für nen guten Zweck:)
Es gibt viele weitere denkbare Szenarien, wo mind. zwei Hardware-Dinger irgendwas machen und spätestens dann muss man sich von der Zentralisierung lösen.
Modbus bedeutet für mich auch modular.
Nee, das war jetzt Quatsch;)state-of-play (iob<->Codesys per Modbus-TCP):
Mod-Adap. als Client geht fein mit DI/Os. Kommen Register hinzu, werden die bins&coils ignoriert und es funzen nur noch die register.
Ggf. eine Überlappung von Speicherbereichen. Allerdings haben sämtl. Änderungen an den Einstellungen nichts gebracht.
Mod-Adap. als Server funkt wild in der Gegend rum, die Instanz-Objekte bleiben aber gelb und sind daher nicht verwertbar, und ich habe wirklich ALLE 2^6 Einstellmöglichkeiten probiert.@minkhx Bei meinem kleinen Test heute Morgen konnte ich Register mit Coils und Discrete Inputs mischen. Die Zeit zwischen schreiben und lesen darf nicht zu kurz sein, wenn der ioBroker noch andere Dinge erledigt. Das hatte ich oben schon geschrieben, dass Modbus Teilnehmer Eigenarten aufweisen können. Wieviel Ressourcen Codesys braucht, ist mit nicht bekannt. Evtl. ist da auch der Flaschenhals.
Ich selbst frage darüber vier Stromzähler ab, wobei einer eine Direktverbindung hat. Da steht zwar Modbus drauf, ist aber wohl nur RS485 Punkt zu Punkt. Da gibt es auch keine Adressen. Die drei anderen Zähler hängen alle an einem Bus und da musste ich schon an den Timings feilen und Abfragen stückeln. Die Probleme gibt es bei alternativen Protokollen, wie z.B. klassisches Ethernet-TCP nicht. Da kümmert sich die Hardware selbst bei Kollisionen.
Der Raspberry Pi sollte ein aktueller mit 4 oder 8 GB sein. Dann schafft der locker mehr Aufgaben. Grafana und InfluxDB habe ich auf separaten VMs. Ob der Pi da ausreichend Ressourcen für alles gewünschte hat, weiß ich nicht. Es nutzen allerdings einige Boarduser einen Raspi für ioBroker.
-
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
Influx, Grafana, Visu. Das Optimieren der Automation über einen Zyklus erscheint mir in diesem Kontext sinnvoll.
Zus. vllt. auch IP-Cams (min. 1080p), die durch die Visu bereitgestellt werden müssten.
Kommen dann noch zeitkontinuierliche Messwertgeber eines Controllers über Modbus rein, dann ists mit einem Pi bald Essig, nehme ich an, für den Fall, dass zB 5 Teilnehmer auf diese Zentrale zugreifen.Hierfür bietet sich ein Mini PC z.B. NUC oder etwas ähnliches an. Einige viele verwenden darauf dann Proxmox und für die einzelnen Systeme dann LXC (Container) oder VMs. Alles auf einem Rechner Nativ würde ich persönlich nicht empfehlen. Alternativ sind auch einige bei Unraid gelandet.
Nurmal so: bei mir läuft Proxmox auf einem Lüfterlosen PC mit ca. 20Watt Verbrauch im Schnitt und diesen CTs/VMs
Und dieser Auslastung:
Ich greife von 3 Teilnehmern (Jeweils PI5 mit Touchdisplay) zur VIS Anzeige darauf zu.
IP Cams erfordern eh gesonderte Behandlung da die meisten RTSP Streams liefern die so nicht mehr im Browser und damit jeglicher VIS angezeigt werden können. Hier gibt es z.B. Motioneye, AgentDVR, Go2RTC, Frigate und nur einige aufzuzählen.
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit.
Keine Ahnung was du damit meinst.
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
Indem man zB die Cam-Stream in dezentrale Pis/Visu einbindet, könnte man die Zentrale deutlich entlasten, denke ich mal.
Wie bereits geschrieben benötigen die extra Behandlung. Ob und welchen Stream man dann wie und wo in die jeweilige Anzeige einbaut macht bei richtiger Einstellung nicht soviel Prozessor last beim Host aus.
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
(Es gibt vllt. auch Tablets, wo man ein Linux flashen kann, aber bleiben wir bei Pi, also Pi+HMI.
Alle Tablets die mit Android laufen, laufen quasi auf Linux. Dort z.b. den Kiosk Browser nutzen und man kann mit dem Tablet fast alles machen so es denn genug Leistung hat. Alternativ ein Dummes Display oder Touchdisplay wenn denn Bedienung gewünscht ist, PI dahinter der dann "nur" die VIS ANZEIGE macht und fertig. Läuft bei mir z.B. 3mal im Haus.
Wenn du aber eh Rechner verteilen willst würde ich bei iobroker über ein Master / Slave System nachdenken. Ich glaube das würde dir langfristig das ein oder andere ersparen, wie z.B. die Modbus Geschichte mit Codesys.... von der ich immer noch nicht zu 100% verstanden habe warum du das nicht mit iobroker Master - Slave - RPI Adapter umsetzt.
Je nach Rechner könnte man den dann auch parallel zur VIS Anzeige nutzen.
@wendy2702 Holla 28 GB RAM-usage ist aber schon ordentlich.
20 Watt ist auch nicht schlechter als ein Pi.
Danke für den screen mit der Auslastung. Das ist hilfreich.Ist pve die VM und darunter die Container?
VM drauf klingt gut. Das ganze rumgebridge mit den Containern will ich mir erstmal nicht antun, bis ich die Funktionstüchtigkeit des Modbus-Adapters ergründet habe.Ja, so ein NAS ist vllt. eine feine Sache, da man ja eh noch vids und pics usw. hat, eine gute all-in-one Lösung.
Vllt. ein PC mit NAS-Ware, da man da einfacher den RAM erweitern kann. Unrais scheint sowas zu sein.Neben RTSP gibt es aber noch andere Zugriffsmöglichkeiten, die im Browser darstellbar sind, soweit ich mich erinnere.
"Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit."
Damit meinte ich, dass die Zentrale, abgespeckt auf eine influxDB per flux auch selber die Modbus-Daten abholen kann. Ohne ioBroker-Overhead. Dann hätte man auf dem zB "PC-NAS" sein Datengrab+Datenbank und ggf. noch Grafana für ein einfaches Admin-Dash.
ioB ist für mich ein "Adapter-Hotel", von denen ich nur die wenigsten benötige.
Es sollte nur als Modbus-Watcher hier im Testlauf fungieren. Ggf. die DB mit einbeziehen. Es soll möglichst keine Logik ausgeführt werden. Nur was für Modbus<->Adapter an scripting nötig ist.
Und letztlich halte ich nur noch daran fest, weil die Visu (so verstehe ich es) losgelöst von irgendwelchen Themes (vis, HQWidgets, HAB) komplett individuell gestaltet werden kann.?
Das ist wirklich ein riesen Vorteil.Ich sehe ioB nicht als Mittelpunkt einer Heimautomation in Bezug auf das beispielhafte Szenario.
Daher der interdisziplinäre Ansatz. Und Modbus TCP käme mir dafür ganz recht.Für mich zusammengefasst Rechner verteilen entlastet die Zentrale, wenn Zentralvisu+Zentrallogik.
Verteilte Rechner als Pi ausgeführt ist besser, weil man da mehr rumfrickeln kann als am Tablet;)
Ein Tablet zB könnte keine Raumtemps aufnehmen oder Luftfeuchten bzw. kenne ich keine Break-Outs hierfür. -
@wendy2702 Holla 28 GB RAM-usage ist aber schon ordentlich.
20 Watt ist auch nicht schlechter als ein Pi.
Danke für den screen mit der Auslastung. Das ist hilfreich.Ist pve die VM und darunter die Container?
VM drauf klingt gut. Das ganze rumgebridge mit den Containern will ich mir erstmal nicht antun, bis ich die Funktionstüchtigkeit des Modbus-Adapters ergründet habe.Ja, so ein NAS ist vllt. eine feine Sache, da man ja eh noch vids und pics usw. hat, eine gute all-in-one Lösung.
Vllt. ein PC mit NAS-Ware, da man da einfacher den RAM erweitern kann. Unrais scheint sowas zu sein.Neben RTSP gibt es aber noch andere Zugriffsmöglichkeiten, die im Browser darstellbar sind, soweit ich mich erinnere.
"Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit."
Damit meinte ich, dass die Zentrale, abgespeckt auf eine influxDB per flux auch selber die Modbus-Daten abholen kann. Ohne ioBroker-Overhead. Dann hätte man auf dem zB "PC-NAS" sein Datengrab+Datenbank und ggf. noch Grafana für ein einfaches Admin-Dash.
ioB ist für mich ein "Adapter-Hotel", von denen ich nur die wenigsten benötige.
Es sollte nur als Modbus-Watcher hier im Testlauf fungieren. Ggf. die DB mit einbeziehen. Es soll möglichst keine Logik ausgeführt werden. Nur was für Modbus<->Adapter an scripting nötig ist.
Und letztlich halte ich nur noch daran fest, weil die Visu (so verstehe ich es) losgelöst von irgendwelchen Themes (vis, HQWidgets, HAB) komplett individuell gestaltet werden kann.?
Das ist wirklich ein riesen Vorteil.Ich sehe ioB nicht als Mittelpunkt einer Heimautomation in Bezug auf das beispielhafte Szenario.
Daher der interdisziplinäre Ansatz. Und Modbus TCP käme mir dafür ganz recht.Für mich zusammengefasst Rechner verteilen entlastet die Zentrale, wenn Zentralvisu+Zentrallogik.
Verteilte Rechner als Pi ausgeführt ist besser, weil man da mehr rumfrickeln kann als am Tablet;)
Ein Tablet zB könnte keine Raumtemps aufnehmen oder Luftfeuchten bzw. kenne ich keine Break-Outs hierfür. -
@wendy2702 Holla 28 GB RAM-usage ist aber schon ordentlich.
20 Watt ist auch nicht schlechter als ein Pi.
Danke für den screen mit der Auslastung. Das ist hilfreich.Ist pve die VM und darunter die Container?
VM drauf klingt gut. Das ganze rumgebridge mit den Containern will ich mir erstmal nicht antun, bis ich die Funktionstüchtigkeit des Modbus-Adapters ergründet habe.Ja, so ein NAS ist vllt. eine feine Sache, da man ja eh noch vids und pics usw. hat, eine gute all-in-one Lösung.
Vllt. ein PC mit NAS-Ware, da man da einfacher den RAM erweitern kann. Unrais scheint sowas zu sein.Neben RTSP gibt es aber noch andere Zugriffsmöglichkeiten, die im Browser darstellbar sind, soweit ich mich erinnere.
"Oder man hält die Zentrale schlank und nutzt nur die influx+Grafana und sammelt über Telegraf fleißig mit."
Damit meinte ich, dass die Zentrale, abgespeckt auf eine influxDB per flux auch selber die Modbus-Daten abholen kann. Ohne ioBroker-Overhead. Dann hätte man auf dem zB "PC-NAS" sein Datengrab+Datenbank und ggf. noch Grafana für ein einfaches Admin-Dash.
ioB ist für mich ein "Adapter-Hotel", von denen ich nur die wenigsten benötige.
Es sollte nur als Modbus-Watcher hier im Testlauf fungieren. Ggf. die DB mit einbeziehen. Es soll möglichst keine Logik ausgeführt werden. Nur was für Modbus<->Adapter an scripting nötig ist.
Und letztlich halte ich nur noch daran fest, weil die Visu (so verstehe ich es) losgelöst von irgendwelchen Themes (vis, HQWidgets, HAB) komplett individuell gestaltet werden kann.?
Das ist wirklich ein riesen Vorteil.Ich sehe ioB nicht als Mittelpunkt einer Heimautomation in Bezug auf das beispielhafte Szenario.
Daher der interdisziplinäre Ansatz. Und Modbus TCP käme mir dafür ganz recht.Für mich zusammengefasst Rechner verteilen entlastet die Zentrale, wenn Zentralvisu+Zentrallogik.
Verteilte Rechner als Pi ausgeführt ist besser, weil man da mehr rumfrickeln kann als am Tablet;)
Ein Tablet zB könnte keine Raumtemps aufnehmen oder Luftfeuchten bzw. kenne ich keine Break-Outs hierfür.@minkhx beschäftige dich besser erstmal weiter mit deinem, für mich immer noch nicht klaren Ziel der Modbus Verbindung.
Leider verrätst du keinem das wirkliche Endziel und warum Codesys verwendet wird bzw. Verwendet werden muss.
Das finale Ziel kann es ja wohl kaum sein eine LED bei Mute zum leuchten zu bringen.
Vielleicht auch nochmal oder überhaupt mal hier lesen https://www.iobroker.net/ was iobroker ist, macht und kann.
Schönen Sonntagabend.
-
@minkhx Bei meinem kleinen Test heute Morgen konnte ich Register mit Coils und Discrete Inputs mischen. Die Zeit zwischen schreiben und lesen darf nicht zu kurz sein, wenn der ioBroker noch andere Dinge erledigt. Das hatte ich oben schon geschrieben, dass Modbus Teilnehmer Eigenarten aufweisen können. Wieviel Ressourcen Codesys braucht, ist mit nicht bekannt. Evtl. ist da auch der Flaschenhals.
Ich selbst frage darüber vier Stromzähler ab, wobei einer eine Direktverbindung hat. Da steht zwar Modbus drauf, ist aber wohl nur RS485 Punkt zu Punkt. Da gibt es auch keine Adressen. Die drei anderen Zähler hängen alle an einem Bus und da musste ich schon an den Timings feilen und Abfragen stückeln. Die Probleme gibt es bei alternativen Protokollen, wie z.B. klassisches Ethernet-TCP nicht. Da kümmert sich die Hardware selbst bei Kollisionen.
Der Raspberry Pi sollte ein aktueller mit 4 oder 8 GB sein. Dann schafft der locker mehr Aufgaben. Grafana und InfluxDB habe ich auf separaten VMs. Ob der Pi da ausreichend Ressourcen für alles gewünschte hat, weiß ich nicht. Es nutzen allerdings einige Boarduser einen Raspi für ioBroker.
@peterfido Tja, bei der Einfachheit des Modbus-Protokolles ist die Kollisionsbehandlung etwas auf der Strecke geblieben. Man kann nicht alles haben:)
-
@minkhx beschäftige dich besser erstmal weiter mit deinem, für mich immer noch nicht klaren Ziel der Modbus Verbindung.
Leider verrätst du keinem das wirkliche Endziel und warum Codesys verwendet wird bzw. Verwendet werden muss.
Das finale Ziel kann es ja wohl kaum sein eine LED bei Mute zum leuchten zu bringen.
Vielleicht auch nochmal oder überhaupt mal hier lesen https://www.iobroker.net/ was iobroker ist, macht und kann.
Schönen Sonntagabend.
@wendy2702 Da steht aber nichts von Multicore-Fähigkeit?
Nur das hier:"In einem Multihost-System mit mehreren ioBroker-Servern können Instanzen von Adaptern auch auf verschiedenen Servern verteilt werden. Dadurch kann die Last verteilt oder direkt vor Ort zusätzliche Hardware angebunden werden (z.B. IO-Ports, USB)."
Und das war mir vorher klar und Grundlage für den Testlauf. Nur eben nicht ioB-Solitär.
Die Ziele habe ich klar formuliert.
-
@wendy2702 Da steht aber nichts von Multicore-Fähigkeit?
Nur das hier:"In einem Multihost-System mit mehreren ioBroker-Servern können Instanzen von Adaptern auch auf verschiedenen Servern verteilt werden. Dadurch kann die Last verteilt oder direkt vor Ort zusätzliche Hardware angebunden werden (z.B. IO-Ports, USB)."
Und das war mir vorher klar und Grundlage für den Testlauf. Nur eben nicht ioB-Solitär.
Die Ziele habe ich klar formuliert.
@minkhx ioBroker läuft unter node-js. Die meisten nutzen als Host ein Linux. Ich selbst nutze Debian VMs unter Proxmox. Die laufen unauffällig durch. Der VM habe ich vier Kerne zugewiesen, welche auch alle genutzt werden. Zwei Kerne sind das Minimum, welches ich zuweise. Bei nur einem Kern braucht Debmatic mehrer fünf Minuten, bis es hochgefahren ist. Bei zwei Kernen etwa eine.
-
@minkhx ioBroker läuft unter node-js. Die meisten nutzen als Host ein Linux. Ich selbst nutze Debian VMs unter Proxmox. Die laufen unauffällig durch. Der VM habe ich vier Kerne zugewiesen, welche auch alle genutzt werden. Zwei Kerne sind das Minimum, welches ich zuweise. Bei nur einem Kern braucht Debmatic mehrer fünf Minuten, bis es hochgefahren ist. Bei zwei Kernen etwa eine.
Modbus-Test abgeschlossen. Der Adapter taugt für micht nichts. Als Client, wie beschrieben, so lala, als Server hat es nichts gebracht. Ich rate davon ab. Vllt. um einen WR auszulesen brauchbar, aber das war ja nicht das Ziel.
Der Quelltext sieht so aus, als ob alles vollständig implementiert ist, aber mehr Zeit verbringe ich damit nicht mehr.MQTT ist mir zu kryptisch per Variablennamen, Funktionsaufrufen etc. Das straight-forward einzubinden ist müßig für komplexere Strukturen. Sicherlich gibt es Frameworks, die über MQTT abstrahieren, aber es ändert den Kern der Sache nicht.
Letztlich hat sich OPC UA bewährt, nahezu reibungslos, auch mit NodeRed.
(Von dem OPC-Adapter rate ich ab)
Die Zertifikate bringen auf allen Teilnehmerseiten zwar ein paar Eigenheiten mit, aber dafür hat man ggü. MQTT auch ein objektorientiertes und transportübergreifendes Protokoll mit allen Finessen.
Nur leider deutlich mehr Overhead als Modbus.
Influx lässt sich anbinden. Was will man mehr:)
Support us
824
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge