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

[swiss]

Hallo Stefan

Danke für deine Rückmeldung. Nach deinem Post habe ich meinen Testaufbau so umgestellt, das jeweils nur 1 Input und 1 Output die gleiche GA haben. Damit funktioniert nun die Ansteuerung aller Outputs problemlos. Es scheint also tatsächlich daran zu liegen, dass nicht mehrere Outputs auf die gleiche GA reagieren können.

Ist aber lediglich ein Softwareproblem, dass sich mit einem Update beheben lassen würde? Dann fände ich dass sehr sinvoll

[dombn]

Kurzbericht: ich habe den MultiIO mit der 2. Charge erhalten. Angeschlossen habe ich Fenster-Reed-Kontakte (von ABUS, NC).

• parasitär angeschlossen,wie bei NetzFritz in #143 dargestellt (https://knx-user-forum.de/294831-post143.html)
• in einem 1wire-Zweig mit 9 Temperatursensoren
• nach Reload erschienen die IOs sofort im Webmin
• Fenster-Reedkontakte mit Leitungslängen zwischen 1m und 5m

Sorry, wenn der Bericht etwas »langweilig« ist. Mehr schaffe ich momenatn zeitlich leider nicht.



@StefanW: Sollte das für die Bedingungen nicht ausreichen, schick mir bitte per E-Mail oder PN eine Adresse eines anderen Testers. Dann sende ich ihm den IO per Post.

[Astrafahrer]

Nächste Schritte:
Ich muss noch die Low-Current-LEDs besorgen, meinen Zimmerbrunnen entsprechend mit den LED´s versehen und dann den Multi-I/O hinter dem Pflanzsubstrat für die Kakteen verstecken (der Brunnen ist ohne Wasser und reine Deko). Dann habe ich eine schöne unauffällige Anzeigeeinheit auf dem Schreibtisch die mich über verschiedene Zustände (Post da, etc.) informieren kann. Sobald ich weiter gebastelt habe gibt es Fotos und ein abschließendes Statement. Danke an der Stelle an Stefan & Team für die Möglichkeit!

Hallo zusammen,
mein "Projekt" neigt sich dem Ende entgegen und ich will weiter berichten. Die Vorgeschichte gibt es unter https://knx-user-forum.de/292861-post105.html.

Ich habe mittlerweile die Low-Current-LED´s erhalten. Beim Test musste ich feststellen, dass die gewählten LED´s sehr dunkel sind (1,5 mcd). Ich habe dann nochmals neue LED bestellt mit 8 mcd. Diese sind ausreichend hell und lassen sich mit einem 1,5 kOhm Widerstand mit knapp 2 mA an 5 Volt betreiben.

Damit konnte der Aufbau beginnen:

Step 1: Brunnen vorbereiten
Mit einem 3 mm Bohrer habe ich 6 Löcher für die LED´s in den Brunnen gebohrt.



Step 2: LED´s auswählen und einbauen
Die zuerst ausgewählten LED´s waren zu dunkel (linkes Bild). Daher habe ich neue LED´s besorgt (rechts). Das besondere am Brunnen ist aus meiner Sicht, dass er eben ohne externe Spannungsversorgung auskommt und der Multi I/O sowie die LED´s über die 5 Volt des Busmasters versorgt werden. Daher waren Low-Current-LED´s mit einer Stromaufnahme von 2 mA notwendig.



Step 3: Einbau und Betrieb
Ich habe die LED´s jeweils mit Vorwiderstand "im Stern" eingebaut und mit der Plus - Seite direkt an die 5 Volt der Multi I/O - Klemme angeschlossen. Die Minus - Seite geht jeweils die auf Ausgänge 1A bis 3B.


Step 4: Fertig
Die LED´s sind eingebaut, der Multi I/O ist angeschlossen und jede LED hat eine GA. Damit kann ich nun diverse Informationen anzeigen, derzeit aber noch ohne "sinnvolle" Belegung.



Step 5: LED - Lauflicht
Ich habe auf Basis des Blinker - Plugins versucht ein Lauflicht - Plugin zu schreiben. Wenn jemand ein fertiges Plugin hat oder "schnell mal" ein Plugin für die 4 GA´s schreiben möchte, dann gerne her damit; Ich muss mich dazu erst noch ein arbeiten.

[chris5020]

Hallo Stefan,

das mit der Relaiskarte war nicht so gemeint, ich bau grad selber was in die richtung.

Mit war nicht klar, dass es beim BetaTest nur darum ging, die Sensoren in möglichst vielen 1-wire-Installationen hängen zu haben, ohne dass es da einen praktischen Einsatzzweck gibt.
Wenn es nur um LED und Reed geht, dann funktioniert das bei mir.

Ich werd mal versuchen dieses Wochenende einen Schritt weiter zu kommen.

lg, chris

[StefanW]

Guten Morgen Chris,

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

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.

Schon richtig, nur, so sehr ich den Wunsch nach einem Gesamtkunstwerk verstehe, der Beta-Test sollte kein Kreativitätswettbewerb werden - schon aus zeitlichen Gründen. Für den Test der IOs ist es schließlich egal, was hinten dran hängt, eine LED oder die Schnellabschaltung vom Atomkraftwerk - auch wenn die Folgen und der Nutzwert natürlich unterschiedlich sind.

Aber: Es war auch extra nichts vorgegeben von unserer Seite, weil wir auch sehen wollten, was die Anwender damit machen wollen.

So allgemeine Spielereien wie LED oder Reed hab ich auch gemacht, aber das ist nicht testwürdig.

Doch, durchaus. Es ging uns beim Test insbesondere auch darum, den Multi-IO an einer Vielzahl bestehenden Installationen zu testen (also 1-Wire Busen / WireGates). Einfach um zu sehen, ob es mit bestimmten Konstellationen von 1-Wire Slaves in real existierenden Netzen - die in bisherigen Tests evt. nicht berücksichtigt wurden - zu Inkompatibilitäten kommt.

Daher wäre es mir lieber, wenn 30 Tester nur die Reeds von Fenstern / Türen anschließen und nach einigen Wochen berichten, dass alles einwandfrei funktioniert. Weil damit wissen wir, dass die Technik prinzipiell in bestehenden Netzen beim Kunden tut und es zu keinen Instabilitäten (insbesondere auch der Software) kommt.

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.

Ich verstehe das schon. Du willst einen größeren Test in einer komplexen technischen Lösung machen, das ist im Prinzip auch ok und interessant. Ich setze mir das mal auf unsere Liste, dass es in Deinem Fall dann länger dauert.

werd versuchen die Relaiskarte nachzubauen.

Wir haben leider nur zwei Prototypen davon. Die nächsten Platinen aus der Serie kommen erst in 2,5 Wochen. Ich spreche mal intern, ob wir den Prototypen entbehren können.

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.

Ja, an das Zeitlimit werden wir künftig denken, das haben wir gelernt.

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.

Das entspricht etwa den meisten Rückmeldungen. Wir holen bereits die Angebote für die 2er und die 4er Variante ein.

Mit separatem Treiber wird es eine extra Platine werden, das kommt nicht als erstes, halten wir aber im Auge. Es gibt aber noch versprochene Projekte die umgesetzt werden müssen (Umgebungslichtsensor, VOC) und daher Prio haben.


lg

Stefan

[Bodo]

Funktioniert einwandfrei

Hoi

Hab' den Multi-IO am Bus. Den Türkontakt aufgelegt, funktioniert erwartungsgemäss. Das Signal ist nach 1-2 sec. auf dem Bus.

PS [selbstironie_an] und war das so schwer? [selbstironie_aus]

[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

[Frank65]

Probiere mal -1. Sollte klappen.

Damit hat es funktioniert.

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

Gruß, Frank

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

[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]

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

[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

[JuMi2006]

Probiere mal -1. Sollte klappen.

[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

[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