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:)

@bananajoe said in Als Einsteiger - Mit welcher Visualisierung beginnen?:

In VIS1 / VIS2 hat jedes Gerät seine eigene Instanz-ID (bzw. man kann eine erzeugen),

und View-in-Widget klingt gut. Vielen Dank.

@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.

@peterfido Tja, bei der Einfachheit des Modbus-Protokolles ist die Kollisionsbehandlung etwas auf der Strecke geblieben. Man kann nicht alles haben:)

@minkhx ISt ioB in diesem Zusammenhang Multithread/core-fähig?

@peterfido Alles klar, besten Dank.

@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.

@peterfido Hallo Peter, vielen Dank fürs Zeigen.
Das gibt mir auch gleich nen Einstieg in Nodered und JS:)

Wird das JS-Uhraktscript irgendwo im Nodered eingebaut (mit Doppelklick auf blaue Box oben links "0_userdata.0.Modbus.Uhrakt:true") oder wird das im JS-Adapter erstellt und dann dort gestartet, wenn es benötigt wird?
Es scheint ja auch zwei verschiedene Skripte zu geben?
Das zweite sieht aus, als wäre es die Klartextdarstellung des Node-Flows, oder?
Kann ich das dann iwo reinkopieren und hab die Knoten? Wär ja geil:)
Oder gibts da Probleme mit den Hexen? ZB "server": "8f608791ee2c56ec"?

Wie bei Dir zu sehen, habe auch ich keinen Var-Namen unter Discrete-Inputs im Modbus-Adapter angegeben, nur eine Adresse und trotzdem kommen Werte. Gespentisch:)
Wenn ich mehrere Byte-Typen habe, wäre allerdings schon eine Unterscheidung erforderlich, welches Bit ich gerade nutzen will. Da erschließt sich mir die Struktur des Adapters noch nicht so recht. Schließlich will man ja auch für die Les- und Wartbarkeit nicht nur Adress-Zahlen handlen...
Allein z.B. die Beschreibung oder einfach trotzdem einen Var-Namen zu vergeben, ist nicht eindeutig, wenn es denn scheinbar auch ohne geht.
Oder tauchen im Nodered dann konkrete Zuordnungen auf?

ZB (Heimautomationsanwendung) Codesys-Gegenseite:
Var
Zi1 : Byte;

Begin
if
Zi1.0 = %DI1; //(Rolladen_Endlage_offen)
...
Zi1.7 = Fenster_Fensterkontakt_auf;
usw.
End;

Erwartung im Modbus-Adapter (Konfi-Tab Discrete Inputs):
Adresse: 0
Name: Zi1
Beschreibung: Rolladen offen
Role: state
usw.

@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 Hmmm, trotz logout, werde ich als online gezeigt und kriege ständig dieses approval...
Ja, mehrere Pis jeweils mit ioB.