- √ - Öffentlicher Beta-Test 1-Wire Multi-IO 6-fach (war Sylvester-Kracher 2012)

[Dirk42]

Ich hätte da einen Multi-IO für Dich. Ein Forenkollege hat mir gestern geschrieben, dass er seinen Multi-IO zurückgeben würde, weil er gerade Trouble am Bau hat, ich würde ihm einfach Deine Adresse schreiben (ist die mit den Mühlwegen richtig für Versand?)

Super-genial! Ich heize schon mal den Lötkolben auf... die Adresse mit den Mühlwegen ist korrekt für Versand.

[chris5020]

Stimmt, der Testen und Bericht war natürlich eine der Bedingungen für den Test, aber innerhalb von 4 Wochen ist hier natürlich nix vernünftiges möglich.

Eigentlich hatte ich auch gleich Mitte Jänner nach dem Erhalt vor mir hier ein vernünftiges Projekt auszudenken, das hab ich auch getan.

Ansteuerung des Motorschloss der Türe inkl. Überwachung, d.h.
- Erkennen ob Türe offen/geschlossen
- Erkennen bzw. Aktivieren der Tag-Schaltung
- eventuell sogar Betätigung.

Das ist aber natürlich nix, was man mal schnell so in der Praxis umsetzt.
So allgemeine Spielereien wie LED oder Reed hab ich auch gemacht, aber das ist nicht testwürdig.

Für einen vernünftigen Test sind hier leider einige Vorarbeiten notwendig, etwa Leitung zum Motorschloss legen, Auswerten bzw. Ausmessen der Ausgänge, entwerfen einer notwendigen Beschaltung (wie die gerade vorgestellte Relaiskarte). Dann muss man das ganze natürlich noch besorgen und zusammenbauen.
Nachdem ich dann einen Woche weg war und jetzt auch noch brav die Grippe hatte war hier natürlich wenig Zeit für das Ganze.
Und eigentlich ist dafür nur am Wochenende wirklich Zeit, daher wird es hier für einen sauberen Test sicher noch ein wenig dauern.

Was ist der Status:
Ich hab jetzt endlich mal das Kabel vom Wiregate zum Motorschloss verlegt, und ein paar Versuche gemacht, allerdings muss ich mir noch eine vernünftige Ansteuerung des Relais für die Schaltung machen, werd versuchen die Relaiskarte nachzubauen. Sobald das ganze mal dann endlich im Echtbetrieb ist werde ich auch möglichst rasch einen Testbericht abliefern.

Danke auf jeden Fall für die tolle Aktion und das nächste Mal vielleicht gleich vorab ein Zeitlimit vorgeben, dann hätte ich das vielleicht auch gelassen.

Bezüglich der Varianten:
Ich denke 6 I/Os sind für viele Anwendungen fast zu viel, 4 wären hier ideal, eventuell könnte man dafür auf der Platine noch Platz für einen Treiber vorsehen, damit man direkt ein Relais anschliessen kann.

schönen Abend, Chris

[LoneWolf HD]

Hallo!

Varianten mit 6, oder auch 4 oder 2 IO-Ports:
Für mich würden die Varianten mit 2 oder 4 Ports in Frage kommen.
Möchte sie hauptsächlich für Reedkontakte der Fenster benutzen und mehr
als 3 Fenster hab ich in keinem Raum. Insgesamt wären das bei mir
5 Dachflächenfenster und 14 Fenster.
Muß meine Verrohrung und Dosen erst machen. Wenn jetzt bis Mitte des Jahres
die I/Os verfügbar wären, würde ich gleich alles dafür vorbereiten...

Betauungsresistenz:
In manchen Räumen wäre das auch bei mir sinnvoll. Denke da grad an die
große Garage/Werkstatt bzw. Waschküche.

Auf jeden Fall schon mal ein riesiges Dankeschön für Eure Bemühungen!!!

[StefanW]

Super-genial! Ich heize schon mal den Lötkolben auf... die Adresse mit den Mühlwegen ist korrekt für Versand.

Der Kollege hat mit geschrieben, dass er es heute an Dich abgeschickt hat.

BTW: Aber der Multi-IO ist schon gelötet

[stb]

Hallo,

zur Bedarfsabfrage:
ad 1) Habe Bedarf an "einer Schachtel voll" von den 2fachen und dazu zwei 4fache für Fensterkontakte. Auf Vorrat oder als Ausfallreserve würde ich mir da nicht unbedingt brach liegende IOs dazupacken wollen -- kann das Modul ja bei Bedarf gegen ein Größeres tauschen.
ad 2) derzeit kein Bedarf (Bauphase... erst mal die basics umsetzen)
ad 3) derzeit kein Bedarf, aber 5 EUR Aufpreis würde ich später gezielt für Briefkasten & Co schon investieren

Ansonsten: Ihr habt tolle Produkte, eine schnelle Bestellabwicklung (diese Woche wieder einmal super fix geliefert), Support und Umgang mit Kunden ist vorbildlich. Bitte weiter so.

[Frank65]

Hallo Stefan,

bei mir läuft der Multi-IO nun schon einige Zeit in der Garage und wird (wie in Post 116 von mir beschrieben) alle 60 sek mit einem Befehl auf eine Ausgabe angesteuert, die direkt auf einen Eingang verdrahtet ist. Mit 30 sek Versatz wird die Ausgabe dann wieder auf 0 gesetzt. Im HS zähle ich die ausgegebenen Befehle und die rückgelesenen Eingänge.

Soweit funktioniert alles und die rückgelesenen Eingänge folgenden den Befehlsausgaben.

Ich habe aber festgestellt, dass ich mehr Rückmeldungen zähle, als wie ich Befehle ausgebe. Das hat mich kurz verwirrt, bis mir eingefallen ist, dass ich noch einen überlagerten Sendezyklus von 300 sek im Webmin eingestellt habe.

Den habe ich dann auf 0 sek gesetzt, war mir da aber schon unsicher, ob 0 sek der richtige Wert ist wenn ich keinen überlagerten Sendezyklus haben will. Trotzdem abgespeichert und anschließend festgestellt dass die zusätzlichen Rückmeldungen trotzdem noch kommen.

Anschließend den Wert auf Blank gesetzt, also gar keinen Wert eingetragen und wieder abgespeichert (Zustand jetzt siehe Bild). Trotzdem kommen noch immer die zusätzlichen Rückmeldungen, die man daran erkennt, dass sie außerhalb des 60 sek. Rhythmus im Busprotokoll erscheinen (auch hierzu ein Bild beigefügt)

Irgendwie sieht das für mich so aus, als wenn ich den überlagerten Sendezyklus im Webmin nicht deaktivieren kann und er sich auf einen krummen Wert so um die 100 sek festgelegt hat.

Is it a bug or is it a feature (oder bin ich zu blöd ...) ?

Gruß, Frank

[StefanW]

Guten Morgen Frank,

Is it a bug or is it a feature (oder bin ich zu blöd ...) ?

Wird geprüft!

Edit: Ich denke, es ist ein Feature.

Der KNX-Bus ist zwar eventbasierend aber eben auch mit Statuswiederholungen ausgelegt. Zum Teil werden diese Statuswiederholungen für die Aufrechterhaltung in Caches usw. benötigt, wie folgendes Beispiel zeigt:

Nimm an, Du startest eine CometVisu mit 500 oder mehr Objekten auf einem Client. Dann werden die 500 Stati besser aus dem lokalen Cache des eibd gelesen - anstatt zunächst 500 Lesetelegramme abzusetzen - damit die Visu auf dem Client auch in ein oder zwei Sekunden startet (probiere das mal mit einer pollenden Visu mit 500 Objekten, die braucht 10 Minuten zum starten....). Darum halte ich es für möglich, dass wir aus dem wiregated regelmäßige Stati senden, damit die eibd-Caches immer aktuell und gefüllt sind. Ich muss das aber noch nachfragen.


Stefan

[Frank65]

Wird geprüft!

Edit: Ich denke, es ist ein Feature.

Moin Stefan,

Dann wäre es auch interessant zu wissen, was der richtige Eintrag in das Feld ist, wenn ich den geringstmöglichen Sendezyklus (eigentlich gar keinen) haben will. Null oder Blank. Zumindest waren im Webmin beide Eingaben zulässig (soweit ich mich erinnern kann). Default war wohl blank ?

Gruß, Frank

P.S. Deine Erläuterung mit eibd und der Cometvisu kann ich nicht bewerten, da ich damit keine Erfahrungen habe. Ich habe ja auch mit dem von mir festgestellten Verhalten kein Problem. Ich konnte es mir bisher nur nicht erklären. Bin schon auf die Rückmeldung gespannt

[JuMi2006]

Probiere mal -1. Sollte klappen.

[StefanW]

Guten Morgen Christian,

ich hatte schon die Tage eine Mail mit meinen Testergebnissen an die Supportadresse geschickt.

Danke sehr, haben wir auch bekommen.

Ich versuche aktuell noch Stefans Modellrechnung im Loxonefred nachzurechnen. Denn die anderen Fensterkontakte haben Leitungslängen von ca. 15m - 20m.

Diese Rechnungen stammen ursprünglich aus meinen Beiträgen zur Diskussion um den Multi-IO und dessen Eignung für Fensterkontakte:

https://knx-user-forum.de/169621-post96.html
https://knx-user-forum.de/169857-post104.html
https://knx-user-forum.de/172682-post120.html


Eine kleine Rechnung für Deine 20 m und 5 V:

• Eine J-Y(ST)Y hat einen Kapazitätsbelag von 100 nF/km. Mithin bei 20 m Länge eine Kapazität von 2 nF.

• Ein (Leitungs-) Kondensator speichert bei 2 nF und einer Spannung von 5 V eine Ladungsmenge von 10 nC und eine Energie von 25 nJ.

• Der Reed-Hersteller Meder gibt an, dass bei 50 V und 50 pF (das wäre übrigens nur ein halber Meter Leitungslänge!) die Lebensdauer (von ansonsten Milliarden Schaltspielen) bereits empfindlich beeinträchtigt wird. Diese 50 V und 50 pF entsprächen einer Ladungsmenge von 2,5 nC, jedoch wegen der hohen Spannung einer Energie von 62 nJ.

Allerdings, und das möchte ich nochmal betonen, spielt bei der Betrachtung der Energiemenge die ZEIT eine sehr große Rolle, in der diese über die Leitungs- und Kontaktwiderstände abgebaut (in Wärme verwandelt) wird. Hersteller Meder schreibt, dass der Zeitraum der ersten 50 ns nach dem Schaltereignis entscheidend ist und man den Strom in dieser Zeit kennen muss.

==> Bei Deinen 20 m und 5 V (Multi-IO) würde 1 ns nach dem Schaltvorgang theoretisch* ein Strom von 2,8 A fließen, nach 10 ns etwa 65 mA, also gar nicht so wenig.

Welche Lebensdauerminderung nun damit genau einhergeht kann ich nicht genau sagen. Ich hab hier nur eine handvoll Angaben eines Herstellers und habe damit gerechnet und bin zum Entschluss gekommen, dass die Leitungen so kurz wie möglich und Spannung und Strom ebenfalls so gering wie möglich sein soll um die Lebensdauer der Kontakte zu sichern.
Mit einem Widerstand direkt am Kontakt lässt sich der lebensdauermindernde Effekt allerdings ebenfalls weitgehend reduzieren, weil die Energie dann über einen längeren Zeitraum und über dem Widerstand abgebaut wird.

Es gibt dann auch noch den Abreißfunken beim Öffnen wegen der Selbstinduktionsspannung. Diese hängt u.A. vom Strom und der Geschwindigkeit der Änderung, als auch von der Induktivität (Leitungslänge) ab. Dazu habe ich noch keine Rechnungen angestellt, weil ja das Kondensatorproblem schon groß genug ist und auch der Hersteller hier stärker darauf hinweist.

Die Entscheidung musst Du selbst treffen.

*Für die Physiker und Elektro-Techniker unter Euch: Mir ist bewusst, dass dies theoretische Berechnungen sind die so nicht ganz eintreten werden, da die elektrische Welle des Entladestroms sich nicht in 1 ns über den 20 m langen Leitungskondensator ausbreiten kann, skizziert jedoch trotzdem anschaulich die physikalischen Effekte und die Kontaktbelastung.

lg

Stefan

[swiss]

Soo... Ich bin auch einen Schritt weiter beim testen.

Ich habe immer noch das Problem, dass sich dieOutputnicht so verhalten wie ich es erwarten würde. Da ich erst Probleme mit der Verkabelung 100% ausschliessen wollte, habe ich von der gefärlichen Bastelversion (mit dem abgeschnittenen Anschlusskabel und die ultrafeinen Adern verkemmen) auf eine saubere Lösung mit Übergangskabel RJ12 -> RJ45 und auf der RJ45 seite mit einem Netzwerkkabel (wegen dem Querschnitt) weiter zum MultiIO und IButton Probe.

Was ich beim Testen feststellen konnte...

Wenn ich alle Port A als Ausgänge und Port B als Eingänge konfiguriere und allen 6 Ports die gleiche GA zuwese, geschieht folgendes:

Egal welchen Eingang ich schliesse, wird immer nur der Ausgang 2 geschalten. Dies ist einerseits im Webmin zu erkennen. Aber auch an der LED in der IButtonprobe.

Um auszuschliessen, dass esein Hardwareproblem ist, habe ich mal an den beiden Ports 1A und 3A die nicht auf die GA reagieren getestet, ob es mit einem direkten schalten im OWFS funktioniert. Beide Ports haben aber einwandfrei geschalten.

Nun stelle ich mir die Frage, ob es an der wiregated-ow.pl liegen könnte?

Wenn wir das Problem von zwei seiten versuchen einzugrenzen, können wir folgendes feststellen...

-> OWFS und 1-Wire so wie die Hardware funktionieren.
-> KNX und eibd funktionieren ebenfalls einwandfrei. Die Telegramme sind auch alle schön im log zu sehen.

...also müsste es theoretisch zwischen eibd und OWFS harzen. So weit ich erfahren habe befindet sich dazwischen das wiregated-ow.pl nur wie kann man das debugen? 1 von 3 Konfigurierten Ausgängen funktionieren bei mir über KNX und die 3 Inputs. Der rest nur direkt über OWFS!?

Und es scheint nur bei mir so zu sein was mich stutzig micht. Allerdings bei 2 verschiedenen WG's verschiedenen alters aber mit gleichem PL

[Hauke]

Kann es sein das das Problem darin besteht, dass Ein- und Ausgang die gleiche GA haben? Ich meine das ist doch Zufall was nachher bei raus kommt, oder? Du schaltest den Ausgang beispielsweise ein und sendest ein Telegramm vom Eingang auf die gleiche GA. Wenn du Glück hast, wurde der Wert zwischenzeitlich abgefragt. Vielleicht wurden aber zwischen Schalten und Wert des Eingangs auf den Bus senden nur Temparatursensoren abgefragt... (Makki kann bestimmt genauer sagen ob das sein kann, aber soweit ich mitbekommen habe, kann es bei einer größeren Anzahl Sensoren schon etwas dauern bis allle einmal durch sind, ich denke mal der MultiIO ist da keine Ausnahme)
Wie ist es wenn du eine GA für Schalten und eine für Rückmeldung definierst? Ich könnte mir vorstellen das bei einem handelsüblichen Schaltaktor auch komische Dinge passieren wenn ich Schalten und Rückmeldung auf die gleiche GA lege...

[swiss]

Hallo Hauke

Also mal zu mienem Testaufbau...

Ich habe den MultiIO momentan gerade an dem WG, an dem exklusiv nur der BM für den Test-BUS und der USB-DMX angeschlossen ist.

Das bedeutet, dass nur 1 BM mit momentan 3 BUS Teilnehmer (3x2 IO's) angeschlossen ist. Was WG hat also alle Zeit der Welt die 6 IO's auszuwerten.

Auch wenn ich nur 1 IO als Eingang konfiguriere und alle anderen als Ausgang, schalten nicht alle Ausgänge wenn ich am einen Eingang eine Brücke mache oder ein Telegramm vom KNX auf die GA sende.

Interessanterweise ist es so, dass in dieser Konstellation (1I & 5O) nur 2 Ausgänge schalten. Die befinden sich auch auf dem selben 1-Wire IC Als ob die anderen beiden IC's die umkonfigurierung zum Output nicht ausführen würden bzw. Das WG die IC's intern nicht als Output's erkennt und ansteuert. Denn über OWFS kann ich ja alle Outputs schalten und es funktioniert da auch. Als Eingänge funktionieren alle Ports wunderbar auch über das Webmin...

[Frank65]

Probiere mal -1. Sollte klappen.

Damit hat es funktioniert.

Wenn ich -1 eingebe, kommen keine zusätzlichen Statusrückmeldungen mehr

Gruß, Frank

[StefanW]

Gute Morgen Patrik,

Auch wenn ich nur 1 IO als Eingang konfiguriere und alle anderen als Ausgang, schalten nicht alle Ausgänge wenn ich am einen Eingang eine Brücke mache oder ein Telegramm vom KNX auf die GA sende.

ich würde sagen, es wäre möglich, dass es bisher nicht Bestandteil des Pflichtenheftes war, dass mehrere IOs mit einer GA verbunden sind, also insbesondere als Ausgang. Macht jedoch durchaus Sinn.

Wir werden das intern nachstellen und ggfls. ein Bug-Ticket öffnen.

Vielen Dank für den Hinweis.

Stefan