Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

[gelöst] OWX asynchronous nur 1x möglich?

Begonnen von bismosa, 14 Oktober 2024, 16:19:32

Vorheriges Thema - Nächstes Thema

bismosa

Hallo!

Ich beschäftige mich gerade damit mein FHEM System von einem Raspberry 3b+ auf ein Lenovo ThinCentre m92p (mit Debian in einer VM unter Proxmox) umzustellen.
Da ich vieles über die GPIO realisiert habe, benötige ich dafür einen Ersatz. Ich denke da ist ein Arduino mit Firmata an USB sehr gut geeignet.

Dafür mache ich gerade ein paar tests. Ich habe in meinem Produktivsystem zwei 1-Wire Busse laufen. Die Verkabelung in meinem Haus ging leider nicht anders.
Ich nutze einen Arduino nano mit Optiboot bootloader mit der Configurable_Firmata Version 2.9.2. Ich hoffe das ist richtig, da ich viele alte Beiträge gefunden habe, wo es immer mal mit neueren Versionen Probleme gab. Aber vieles davon war auch veraltet.

Nun habe ich 3 DS18B20 Sensoren auf einer Steckplatine an zwei Ports (Pin11 und Pin12) angeschlossen.
Dafür habe ich auch zwei OWX Devices erstellt.
Sobald ich beide auf
attr OWio4 asynchronous 1laufen lasse, bekomme ich bei dem letzteren den state disconnected. Im Log erhalte ich
2024.10.14 16:01:32 4: OWX_Qomplex: Added dev 28AA0E033C14014B to queue OWio4 context=convert
2024.10.14 16:01:32 1:    queue OWio4 contains 1 entries after insertion
2024.10.14 16:01:32 1:     => 28AA0E033C14014B context convert expecting 1 bytes, waiting
2024.10.14 16:01:32 1: ----------------------------------------------
2024.10.14 16:01:32 1: OWX_Qomplex: Added dev 28AA0E033C14014B to queue OWio4 numread=19
2024.10.14 16:01:32 1:    queue OWio4 contains 2 entries after insertion
2024.10.14 16:01:32 1:     => 28AA0E033C14014B context convert expecting 1 bytes, waiting
2024.10.14 16:01:32 1:     => 28AA0E033C14014B context readsp expecting 19 bytes, waiting
2024.10.14 16:01:32 1: ----------------------------------------------

An den Sensoren scheint es nicht zu liegen. Auch wenn ich die tausche, habe ich bei dem gleichen OWX Device wieder den Status disconnected.

Was kann ich tun, damit beide asynchron laufen? Oder geht dies nicht mit nur einem Arduino?

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Prof. Dr. Peter Henning

#1
ZitatWas kann ich tun, damit beide asynchron laufen? Oder geht dies nicht mit nur einem Arduino?
Natürlich geht das nicht mit nur einem Arduino. Denn der Arduino wird von FHEM als EIN Device angesehen - dass er mehrere 1-Wire-Systeme versorgt, ist dabei unwesentlich.

Was spricht denn dagegen, die beiden Buskabel zusammenzulegen? Natürlich mit entsprechender Vorsorge, also Vermeidung von Sternverkabelung.

Falls das nicht geht, zwei Busmaster (z.B. Arduino) einsetzen. Ich habe 5 verschiedene 1-Wire-Systeme im Haus - und jedes mit einem eigenen Busmaster und einem OWX-Device.

LG

pah

bismosa

Hallo!

Danke für die Rückmeldung.
Heute hatte ich ein zusätzliches Problem mit meinem Firmata Arduino. Er hatte es nicht geschafft zu initialisieren.
Es hat ein wenig gedauert, bis ich herausgefunden habe, das sich ein weiteres Firmata Device per Autocreate angelegt hat. Wodurch konnte ich noch nicht herausfinden. Aber vermutlich ein Bedienerfehler.

Aktuell habe ich wieder beide OWX Module auf asynchronous laufen. Beide haben das IODev "FIRMATA". Also meinen Arduino. Heute klappt dies auch problemlos. Keine Fehler. Auch nach einem Neustart ist noch alles gut.
Ist das also nur ein Zufall, das es gerade funktioniert? Ohne es im Detail zu kennen...ich vermute, das sich die Anfragen an den Arduino im Asynchronen Modus überschneiden und es dadurch zu Problemen kommt?
So ganz ist es für mich noch nicht verständlich, warum ich nur einen 1-Wire Bus pro Device haben kann.

Einen zweiten Arduino für den zweiten Bus ist kein Problem für mich. Ich könnte auch die Verkabelung anpassen, das ich ohne Sternentopologie beide Busse zusammenführe. Am Raspberry über GPIO lief das aber überhaupt nicht stabil...und auch so muss ich alle Paar Tage die Stromversorgung vom Bus trennen um wieder Werte zu erhalten.
Das könnte aber auch mit den 3.3V des Raspberry zu tun haben. Die ersten Sensoren sind ca. 15m entfernt.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Prof. Dr. Peter Henning

Zitat von: bismosa am 15 Oktober 2024, 16:43:48Ist das also nur ein Zufall, das es gerade funktioniert? Ohne es im Detail zu kennen...ich vermute, das sich die Anfragen an den Arduino im Asynchronen Modus überschneiden und es dadurch zu Problemen kommt?
Das halte ich für Zufall. Wie soll denn bitte OWX entscheiden, aus welchem Bus jetzt gerade das Antwortsignal kommt? Es ist insbesondere mit dem 1-Wire-Protokoll nicht darstellbar, dass mehrere 1-Wire-Chips durcheinander auf einem Bus operieren. Da muss immer ein Sende/Empfangspaar abgeschlossen werden.

Synchron ist das kein Problem, weil jeweils auf die Antwort gewartet wird.

LG

pah


bismosa

Alles klar. Danke für die Erklärung. Hätte ja sein können, das da unterschieden wird wer gerade antwortet.
Gut das dies im Vorfeld schon aufgefallen ist. Bei meinen 20 Sensoren würde das vermutlich gar nicht funktionieren.

Also bleibt mir nur mehrere Arduinos (davon habe ich noch ein paar hier rumfliegen) verwenden oder eine extra FHEM Instanz für die 1-Wire Sensoren.
Überlege ich mir noch.

Danke!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Prof. Dr. Peter Henning

Zitat von: bismosa am 15 Oktober 2024, 16:59:48oder eine extra FHEM Instanz für die 1-Wire Sensoren.
Wenn man schon Arduinos verwendet, kann man auch einen Pi Zero einsetzen. Ich habe meine 1-Wire-Installation im Außenbereich bewusst galvanisch vom Rest getrennt. Auf einem Pi Zero läuft ein Extra-FHEM, das zwei USB Busmaster bedient und erst die kumulierten Daten via WLAN an die Hauptinstanz sendet.

LG

pah

bismosa

Ja. Auch eine Idee...vor allem wegen der Trennung.
Allerdings Versuche ich derzeit die Technik mehr zu vereinfachen. Die Raspberry lasse ich nur noch mit einer SSD laufen. Ich hatte oft schlechte Erfahrungen mit den SD Karten. Das wird nur für 1-wire bestimmt nicht nötig sein.

Ich werde da erstmal ein paar Tage drüber nachdenken. Spontan tendiere ich zu einer weiteren fhem Instanz. Ist über eine separate konfig Recht einfach. Es hilft auch die Hauptinstanz etwas aufgeräumter zu lassen.
Dann kann ich mehrere unkritische blockierende Sachen dort laufen lassen.

Danke!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...