NEWS
Modbus: Verbindung zu Codesys-Runtime herstellen
-
@mcm1957
Das Ziel ist, wie in der Definition angegeben. Es sind die formulierten Teilprobleme.
Struktur und Toplolgie stehen fest. Nur die praktische Umsetzung mit ioB ist ungefähr. Ich brauche wirklich keine Ratschläge, wie ich denn das sonst noch so irgendwie umsetzen könnte, auch wenn ich weiß, das diese Ratschläge wirklich sehr gut gemeint sind, glaub mir.Ob es nun eine Heizung, ein Remote I/O oder sonstwas wird, ist nebensächlich. Nur der Fokus auf das Teilproblem ist entscheidend.
So macht man das in der Programmierung. Jeder arbeitet an seinem Modul. Die globale Variablendeklaration, wenn man so will, ist das, worum es hier geht (im aller entferntesten Sinne).Auch in diesem Sinne ist der Hinweis auf das, wie ich es nenne "Middleware", Scripting entscheidend. Danke dafür. Das war ja eine schwere Geburt:)
Ich habe im HA-Forum gar keine Antworten gegeben. Ein kurzer Überblick reichte völlig aus, glaub mir. Sowohl Forum als auch Software. Allein die CLI ist ja wohl der Graus, oder?
Aber wir entfernen uns wieder vom Topic:
Wer hat eine lauffähige ioB-Codesys-Umgebung parat?
Dei ca. 800-900 aktiven usern wird wohl nicht heißen: Es kann nur einen geben! hihihi@minkhx hier gibt es einige Beiträge in denen Codesys zumindest mal erwähnt wird.
Eventuell erwähnst du die entsprechenden User mit einem @ vor dem Usernamen. Wenn die noch aktiv sind erhalten die dann eine Nachricht.
-
@mcm1957
Das Ziel ist, wie in der Definition angegeben. Es sind die formulierten Teilprobleme.
Struktur und Toplolgie stehen fest. Nur die praktische Umsetzung mit ioB ist ungefähr. Ich brauche wirklich keine Ratschläge, wie ich denn das sonst noch so irgendwie umsetzen könnte, auch wenn ich weiß, das diese Ratschläge wirklich sehr gut gemeint sind, glaub mir.Ob es nun eine Heizung, ein Remote I/O oder sonstwas wird, ist nebensächlich. Nur der Fokus auf das Teilproblem ist entscheidend.
So macht man das in der Programmierung. Jeder arbeitet an seinem Modul. Die globale Variablendeklaration, wenn man so will, ist das, worum es hier geht (im aller entferntesten Sinne).Auch in diesem Sinne ist der Hinweis auf das, wie ich es nenne "Middleware", Scripting entscheidend. Danke dafür. Das war ja eine schwere Geburt:)
Ich habe im HA-Forum gar keine Antworten gegeben. Ein kurzer Überblick reichte völlig aus, glaub mir. Sowohl Forum als auch Software. Allein die CLI ist ja wohl der Graus, oder?
Aber wir entfernen uns wieder vom Topic:
Wer hat eine lauffähige ioB-Codesys-Umgebung parat?
Dei ca. 800-900 aktiven usern wird wohl nicht heißen: Es kann nur einen geben! hihihi@minkhx said in Modbus: Verbindung zu Codesys-Runtime herstellen:
Das Ziel ist, wie in der Definition angegeben. Es sind die formulierten Teilprobleme.
Eben - das sind nur TEILprobleme.
Ich habe nach dem GESAMT-Ziel gefragt,Keine Ahnung warum du dich da so streubst zu sagen 'Ich plane meine Heizung - oder was auch immer - so und so zu steuern.` Es wird ja wohl nicht um die Absicherung einer Bank gehenn wo eine Gehimhaltung verständlich wäre.
Struktur und Toplolgie stehen fest. Nur die praktische Umsetzung mit ioB ist ungefähr. Ich brauche wirklich keine Ratschläge, wie ich denn das sonst noch so irgendwie umsetzen könnte, auch wenn ich weiß, das diese Ratschläge wirklich sehr gut gemeint sind, glaub mir.
Mangels Infos wirszt du auch keine bekommen. Wahrscheinlich aber auch keine für die Teilprobleme...
Ob es nun eine Heizung, ein Remote I/O oder sonstwas wird, ist nebensächlich. Nur der Fokus auf das Teilproblem ist entscheidend.
Wenn du meinst ...
So macht man das in der Programmierung. Jeder arbeitet an seinem Modul. Die globale Variablendeklaration, wenn man so will, ist das, worum es hier geht (im aller entferntesten Sinne).
Danke für die Erklärung wie man programmiert. Dann brauchst du hier ja nicht weiter zu fragen. Wir progra mieren unsere Adapter - wie du die dann zusammenstöpselst ist dein Bier. Schau dir die Struktur von ioBroker an, insbesondere die Definitionen der Objekte und States. Das sind die "Variablen" in ioBroker. Und diese sind imemr alle global - zumindest solange niemand Zugriffsrechte setzt.
Aber wir entfernen uns wieder vom Topic:
Wer hat eine lauffähige ioB-Codesys-Umgebung parat?
Dei ca. 800-900 aktiven usern wird wohl nicht heißen: Es kann nur einen geben! hihihiBemühe die Suche im Forum und schau ob du andere Beiträge zu Codesys findest. Ist sicher keine typische Software im ioBROKER IOT Umfeld.
-
@mcm1957
Das Ziel ist, wie in der Definition angegeben. Es sind die formulierten Teilprobleme.
Struktur und Toplolgie stehen fest. Nur die praktische Umsetzung mit ioB ist ungefähr. Ich brauche wirklich keine Ratschläge, wie ich denn das sonst noch so irgendwie umsetzen könnte, auch wenn ich weiß, das diese Ratschläge wirklich sehr gut gemeint sind, glaub mir.Ob es nun eine Heizung, ein Remote I/O oder sonstwas wird, ist nebensächlich. Nur der Fokus auf das Teilproblem ist entscheidend.
So macht man das in der Programmierung. Jeder arbeitet an seinem Modul. Die globale Variablendeklaration, wenn man so will, ist das, worum es hier geht (im aller entferntesten Sinne).Auch in diesem Sinne ist der Hinweis auf das, wie ich es nenne "Middleware", Scripting entscheidend. Danke dafür. Das war ja eine schwere Geburt:)
Ich habe im HA-Forum gar keine Antworten gegeben. Ein kurzer Überblick reichte völlig aus, glaub mir. Sowohl Forum als auch Software. Allein die CLI ist ja wohl der Graus, oder?
Aber wir entfernen uns wieder vom Topic:
Wer hat eine lauffähige ioB-Codesys-Umgebung parat?
Dei ca. 800-900 aktiven usern wird wohl nicht heißen: Es kann nur einen geben! hihihi@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 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
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 "verteilten" 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;)
Das ist ja schon wieder alles off, man, man, man...
-
@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.
Support us
462
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge