NEWS
Modbus: Verbindung zu Codesys-Runtime herstellen
-
@minkhx Codesys kostet meines Wissens nach Geld. Da fehlt mir und wohl den meisten "ioBrokern" die Notwendigkeit. Die Programmierung lässt sich halt auch kostenneutral durchführen.
Mir scheint mit Codesys schießt man in der Heimautomation mit Kanonen auf Spatzen.
Mir fehlt in dem Fall der konkrete Anwendungsfall. Sollen da nur ein paar Adressen / Register gelesen werden, um die Kommunikation zu testen, so fehlt mir die Erfahrung, den ioBroker als Slave einzusetzen.
Du könntest da mal die Node-Red-Nodes nach Modbus Slave durchsuchen, und schauen, was sich damit machen lässt. Die Beschreibungen sind da meist sehr hilfreich. Der Pi müsste dann die Register beim ioBroker anfordern.
Modbus Register sind 16 Bit breit. 1 Bit breit sind Coils oder Discrete Inputs. Um Bandbreite zu sparen würde ich immer ganze Register lesen und das entsprechende Bit maskieren.
Mir fehlen da die Erfahrungen, einen Slave abzubilden und Codesys allgemein.
Da Ethernet vorhanden ist, würde ich einfach ein alternatives Protokoll wählen. Meiner Erfahrung nach kann es trickreich werden, wenn sich unterschiedliche Geräte am Bus befinden. Einige brauchen länger als andere für die Antwort. Andere sorgen für Bitfehler, wenn man zu viele Register auf einmal abfragt. Da heißt es dann Pausen einprogrammieren und / oder Daten häppchenweise holen. Und manchmal muss man noch die Adresse übersetzen.
Edit: Es hat wohl schon jemand geschafft, den Modbus Adapter als Slave zu betreiben. Klick
@peterfido @peterfido
Danke Wendy für den link, und ich dachte, dass ich schon alle Threads aufgesogen hätte:)Es gibt keine spezifische Anwendung. Nur den "generischen Code", wenn man so will. Daraus lassen sich dann viele use-cases abbilden.
Just a fucking com-test.
Nennt es jugendlichen Leichtsinn, wenn ihr wollt;)Codesys ist wie ioB kostenlos. Wenn man mehr will, kosten beide Geld. ZB die Raspi-Runtime oder der vis-Adapter (<-Ich will mir nicht für jedes Gerät eine mail anlegen und die Lizenz erhaschen, ich kauf dann eben eine. Ist ja für nen guten Zweck)
ioB als Adapter-Hotel bzw. Protokoll-Herberge bietet zus. auch stark individualisierbare Visus, aber es hätte auch ein anderes Forum erwischen können muahaha
@peterfido
Der ioB als Master kommt bei mir nicht zum Einsatz, da ich TCP verwende.
Grundsätzlich erfordert eine derartige Konfi aber den Einsatz einer zus. Instanz je weiterem Gerät. Das scheint mir nicht sinnvoll. Wie ne Salve Postenschrot:)Ja, Node Red, ok. Lässt sich hier, wie bei Blockly, Quelltext einbauen bzw. Code statt Node? Man muss ja nicht alles grafisch lösen, ist vllt. dann auch etwas speichereffizienter und näher am Register. Hab keine Ahnung von JS, aber lässt sich da auch C++ oder asm einbauen? Dann könnte man viel leichter low-level code für den stack implementieren.
Modbus Register sind so breit, wie ich sie anlege und benötige.
Im ioB Modbus-Adapter kann ich hierfür ints, dounleints, reals usw. nutzen. Das ist gut.Bei vielen Geräte im Konzept, gebe ich Dir recht, ist man mit MQTT schlanker unterwegs. Funkt man nach außen, läßt sich leicht ein TLS oder ACLs implementieren. Auch die asynchrone Kommunikation usw. bla, bla, bla:)
Ich strukturiere übergreifend dennoch mit Modbus TCP;)
-
@minkhx Codesys kostet meines Wissens nach Geld. Da fehlt mir und wohl den meisten "ioBrokern" die Notwendigkeit. Die Programmierung lässt sich halt auch kostenneutral durchführen.
Mir scheint mit Codesys schießt man in der Heimautomation mit Kanonen auf Spatzen.
Mir fehlt in dem Fall der konkrete Anwendungsfall. Sollen da nur ein paar Adressen / Register gelesen werden, um die Kommunikation zu testen, so fehlt mir die Erfahrung, den ioBroker als Slave einzusetzen.
Du könntest da mal die Node-Red-Nodes nach Modbus Slave durchsuchen, und schauen, was sich damit machen lässt. Die Beschreibungen sind da meist sehr hilfreich. Der Pi müsste dann die Register beim ioBroker anfordern.
Modbus Register sind 16 Bit breit. 1 Bit breit sind Coils oder Discrete Inputs. Um Bandbreite zu sparen würde ich immer ganze Register lesen und das entsprechende Bit maskieren.
Mir fehlen da die Erfahrungen, einen Slave abzubilden und Codesys allgemein.
Da Ethernet vorhanden ist, würde ich einfach ein alternatives Protokoll wählen. Meiner Erfahrung nach kann es trickreich werden, wenn sich unterschiedliche Geräte am Bus befinden. Einige brauchen länger als andere für die Antwort. Andere sorgen für Bitfehler, wenn man zu viele Register auf einmal abfragt. Da heißt es dann Pausen einprogrammieren und / oder Daten häppchenweise holen. Und manchmal muss man noch die Adresse übersetzen.
Edit: Es hat wohl schon jemand geschafft, den Modbus Adapter als Slave zu betreiben. Klick
-
@minkhx denke das mit dem approval ist von der Foren Software gekommen weil, wie auch immer, 3 mal gepostet wurde. Spam Schutz sozusagen.
Vis Lizenz kostet nur Geld wenn du dein Projekt offline betreiben willst.
@wendy2702 Aha, da muss ich mich noch näher mit beschäftigen. Allerdings kann ich nur einen Lizenz-Token je mail-Adresse zapfen.
Habe ich mehrere PIs, was der Fall ist, müsste ich doch eine weitere mail anlegen, oder?
Unabhängig, ob offline oder nicht? -
@wendy2702 Aha, da muss ich mich noch näher mit beschäftigen. Allerdings kann ich nur einen Lizenz-Token je mail-Adresse zapfen.
Habe ich mehrere PIs, was der Fall ist, müsste ich doch eine weitere mail anlegen, oder?
Unabhängig, ob offline oder nicht? -
@minkhx die Anzahl der Pis wird nur interessant wenn jeder eine eigene iobroker vis Installation bekommt.
Allerdings kenne ich so auf Anhieb keinen Anwendungsfall dafür.
@wendy2702 Hmmm, trotz logout, werde ich als online gezeigt und kriege ständig dieses approval...
Ja, mehrere Pis jeweils mit ioB. -
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
@minkhx Was soll das mit mit dem approval?
Das Approval kommt, wie @wendy2702 bereits schrieb von der Forensoftware.
Im Rahmen des Spamschutzes wird u.a. die Bilanz der Bewertungen geprüft.
Ab einer bestimmten negativen Bilanz geht die Software davon aus, dass die Posts Spam enthalten könnten und deswegen negativ bewertet wurden.Jetzt müssen die Moderatoren jeden einzelnen Post von dir freigeben, bis du durch besonders hilfreiche Posts deine Bilanz wieder verbesserst.
Ich habe das gestern Abend beim zubettgehen schnell gemacht, ohne deine offenen Posts überhaupt zu lesen, damit es schnell geht.
Dadurch sind auch alle scheinbar doppelten Posts freigegeben worden.
-
@minkhx sagte in Modbus: Verbindung zu Codesys-Runtime herstellen:
@minkhx Was soll das mit mit dem approval?
Das Approval kommt, wie @wendy2702 bereits schrieb von der Forensoftware.
Im Rahmen des Spamschutzes wird u.a. die Bilanz der Bewertungen geprüft.
Ab einer bestimmten negativen Bilanz geht die Software davon aus, dass die Posts Spam enthalten könnten und deswegen negativ bewertet wurden.Jetzt müssen die Moderatoren jeden einzelnen Post von dir freigeben, bis du durch besonders hilfreiche Posts deine Bilanz wieder verbesserst.
Ich habe das gestern Abend beim zubettgehen schnell gemacht, ohne deine offenen Posts überhaupt zu lesen, damit es schnell geht.
Dadurch sind auch alle scheinbar doppelten Posts freigegeben worden.
-
@wendy2702 Hmmm, trotz logout, werde ich als online gezeigt und kriege ständig dieses approval...
Ja, mehrere Pis jeweils mit ioB.@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.
-
@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.
Support us
879
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge