Mehrere serielle Schnittstellen mit EDOMI möglich?

[mfd]

Gibt es eine Beschränkung hinsichtlich der gleichzeitigen Nutzung mehrerer serieller Schnittstellen bei EDOMI?
Im konkreten Fall ist eine KWL über RS232 angebunden. Diese läuft mit dem zugehörigen LBS seit mehreren Jahren stabil. Es werden im vorgegebenen Intervall (5min) Daten abgefragt und bei Bedarf auch gesendet.

Zusätzlich würde ich gerne zwei elektronische Zähler auslesen.
Einer davon soll den SML-Reader LBS nutzen, produziert dabei aber Fehler, die einen produktiven Einsatz nicht zulassen. Die Kommunikation mit EDOMI scheint in unregelmäßigen Abständen abzubrechen, obwohl am betreffenden seriellen Port weiterhin Daten ankommen.
Der SML-Zähler sendet seine Datenpakete unaufgefordert im 2 Sekunden-Takt. Eine "Eindämmung der Datenflut" ist somit nicht direkt möglich.

Als 4fach USB-Seriell Wandler kommt ein Exsys 1334IS zum Einsatz. Es handelt sich um echte Hardware, ohne Virtualisierung.

Ist eine derartige Konstellation möglich, bzw. hat jemand bereits erfolgreich mehrere seriell angebundene Geräte direkt an EDOMI-Hardware im Einsatz?

[jonofe]

Edomi sind die Schnittstellen egal. Zuerst müssen sie vom OS erkannt und treiberseitig unterstützt werden.
Danach ist es eine Frage des LBS, der die Schnittstellen ansteuert. Das müsste dann der LBS Ersteller beantworten.

Ich würde sowas eher mit einem Moxa machen, um die Komplexität des EDOMI Servers zu verringern und auch im Falle eines Server Fehlers problemslos über Netzwerk von einer anderen Hardware zugreifen zu können.

[mfd]

Ich würde sowas eher mit einem Moxa machen, um die Komplexität des EDOMI Servers zu verringern und auch im Falle eines Server Fehlers problemslos über Netzwerk von einer anderen Hardware zugreifen zu können.

In meinem Fall wären dann 3 Moxa-Geräte (oder eines mit mehreren Eingängen) nötig, was die Komplexität ja auch nicht verringert. Zudem wüsste ich jetzt kein Gerät, mit dem ich übers Netzwerk auf die Stromzähler zugreifen wollte. Im Falle der KWL kann bei einem Serverausfall einfach auf das mitgelieferte Bedien-Display umgeklemmt werden.
Der notwendige Netzwerk-Switch ist ja auch eine zusätzliche Komponente, die ausfallen kann.

Außerdem müsste ich dann die betreffenden LBS zusätzlich für die Moxa-Geräte anpassen, was (für mich) auch nicht trivial erscheint...

[saegefisch]

Meine KWL (von 2004) hat ebenfalls eine RS232. Seit ein paar Tagen denke ich über eine Schnittstelle nach, aber mit MAX3232 an einen ESP8266. Kommunikation dann per MQTT/WLAN. Bin da (RS232) noch Anfänger, aber mit Zuversicht.
Kurz: edomi spricht (SET/GET) dann per MQTT mit der KWL. Weil die Steuerung per edomi immer nur Komfort/addon (z.B: Luftgüte/VOC -> Lüfterstufe) ist, sollte das reichen. Die KWL kann und soll auch weiter auch autark laufen können.

Nur so als alternativer Ansatz.

[jayem0]

Meine KWL (von 2004) hat ebenfalls eine RS232. Seit ein paar Tagen denke ich über eine Schnittstelle nach, aber mit MAX3232 an einen ESP8266. Kommunikation dann per MQTT/WLAN. Bin da (RS232) noch Anfänger, aber mit Zuversicht.
Kurz: edomi spricht (SET/GET) dann per MQTT mit der KWL. Weil die Steuerung per edomi immer nur Komfort/addon (z.B: Luftgüte/VOC -> Lüfterstufe) ist, sollte das reichen. Die KWL kann und soll auch weiter auch autark laufen können.

Nur so als alternativer Ansatz.

Wenn Funk (WiFi) dann würde ich aber auf alle Fälle MQTT mit QoS aktiv nutzen und Rückkanäle (Statuskanäle) mit Zeitstempel und ggfs. Rolling Counter mit vorsehen.

[mfd]

Die Ansteuerung der KWL läuft ja problemlos per RS232. Das würde ich auch nicht ändern wollen.
Mein USB-Seriell-Umsetzer macht eine galvanische Trennung und braucht keine separate Stromversorgung. Der LBS dazu läuft seit jeher problemlos. Viel einfacher geht es nicht.

Problemkandidat ist in erster Linie der Stromzähler und der zugehörige LBS. Aber auch das scheint eher kein Problem der seriellen Schnittstelle zu sein.
Derzeit scheitert es vor allem am oben genannten Fehler:

Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000350.php | Fehlercode: 1 | Zeile: 126 | Allowed memory size of 67108864 bytes exhausted (tried to allocate 71 bytes) FATALERROR

[mfd]

Zwischenzeitlich hatte ich auch das auf der EDOMI-Maschine eingesetzte Tool 'PowerTOP' im Verdacht die USB-Anbindung bzw. die seriellen Schnittstellen negativ zu beeinflussen.
Ein abschließendes Ergebnis liegt aber noch nicht vor.

Falls jemand Erfahrungen - positiv oder negativ - mit 'PowerTOP' gemacht hat, wäre jegliche Information dazu willkommen.

[mfd]

Eine kürzliche Abfrage der USB-Schnittstellen im Terminal der EDOMI-Maschine förderte u.a. folgendes zu Tage:

ttyUSB3: 3 input overrun(s)
ttyUSB3: 38 input overrun(s)
ttyUSB3: 5 input overrun(s)
ttyUSB3: 5 input overrun(s)
ttyUSB3: 516 input overrun(s)
ttyUSB3: 5 input overrun(s)
ttyUSB3: 722 input overrun(s)
ttyUSB3: 892 input overrun(s)
ttyUSB3: 1001 input overrun(s)
ttyUSB3: 956 input overrun(s)
ttyUSB3: 895 input overrun(s)
ttyUSB3: 89 input overrun(s)
ttyUSB3: 853 input overrun(s)
ttyUSB3: 5 input overrun(s)
ttyUSB3: 1037 input overrun(s)
ttyUSB3: 4 input overrun(s)
ttyUSB3: 5 input overrun(s)

Irgendwie klingt das für mich nach einem (dem?) Problem....

Hier steht dazu:

An overrun error generally means that the buffer, usually in the UART peripheral, was already full when a new byte arrived in the receive register. This happens from reading the receiver buffer too infrequently. Usually, reading will be done in response to an interrupt that is generated when the UART receives a byte, or possibly when the UART's receiver buffer reaches a set level of 'fullness' (some UARTs have multi-byte buffers).

Klingt für mich so, als würden die Daten zu selten von der Schnittstelle "abgeholt". Gibt es dagegen Abhilfe?

[mfd]

Leider habe ich keinen wirklichen Lösungsansatz für den "input overrun" Fehler gefunden. Vielleicht hat ja gaert eine Idee, wo ich weitersuchen könnte...
Gibt es edomiseitig Möglichkeiten etwas zu beeinflussen?

[mfd]

Offenbar ist es so, dass der von mir genutzte 4fach USB-RS232 Converter einen 16Byte Buffer mitbringt. Bei einigen anderen Geräten (z.B. Moxa) scheinen es 128 Byte zu sein.
Der sonst häufig eingesetzte CP2102 hat sogar 576 Bytes in Empfangsrichtung.

Wie lässt sich nun herausfinden, wo möglicherweise der Flaschenhals sitzt - beim RS232-Converter (FIFO Buffer), betriebssystemseitig, oder in EDOMI?

[mfd]

Hat wirklich niemand eine Idee?

Auf Verdacht einen anderen USB-RS232-Converter kaufen ist nicht unbedingt günstig, wenn dieser auch eine galvanische Trennung haben soll. Die Auswahl ist da zudem recht überschaubar.
Eine Moxa-Unterstützung ist bei dem/n betreffenden LBS nicht vorhanden.