Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
ich habe den Multisensor wie in einem vorherigen Post beschrieben in meiner ungeheizten Garage laufen und sende alle 60 sek einen Befehl an eine Ausgang und lese ihn gleich über einen Eingang zurück. 30 sek später wird der Ausgang wieder zurück gesetzt
Das lief jetzt eine Woche bei Außentemperaturen zwischen -5 °C und +5 °C durch und hat 10.000 Vorgänge gezählt.
Dabei sind nur 3 Rückmeldungen verloren gegangen
Fehlerquote damit 0,3 Promille
Ich setze das Ganze jetzt auf 0 zurück und lasse die Zähler wieder eine Woche laufen. Werde berichten !
Die Reihenfolge der 3 IOs habe ich durch Drahtbrücken geprüft, aber das war relativ umständlich, weil man oft 2-3x den Frame umständlich neu laden musste.
Beim endgültigen Produkt werden die SNs natürlich auf einem Aufkleber aufgedruckt. Das war nur hier für die Nullserie noch nicht möglich, weil das Testsystem noch nicht fertig ist.
Bezüglich Pullup hatte ich mir schon gedacht, dass da ein interner enthalten ist, eigentlich wollte ich 10K nehmen, keine Ahnung warum ich dann am ende auf 1K gekommen bin
Das kommt natürlich noch in die Doku mit entsprechendem Prinzipschaltbild. Dachte mir fast, dass Du 10 k nehmen wolltest (ist so ein Standardwert für Pullup), aber musste trotzdem auch wegen evt. Nachbauer deutlicher darauf hinweisen.
Danke für die Info mit dem direkt anlegen der 24V, das hatte ich mich nicht getraut, und die knapp 50 Cent für den Eingangsschutz tun mir hier nicht weh.
Der Optokoppler ist natürlich auch sauberer wegen der Potentialtrennung. Aber wir haben die Schaltung extra so ausgelegt, dass auch Signale bis 24 V mit externem Pullup angelegt werden können. So kann auch die Empfindlichkeit usw. herabgesetzt werden.
Kommt ebenfalls in die Doku (die immer umfangreicher wird).
...aber im Normalbetrieb hier 2 Systeme drücken, damit die Türe aufgeht ist unpraktisch.
Ja, das gilt für Sicherheit immer. Wir kommen eigentlich aus dem Bereich "Managed IT Security" und wir haben 2-Faktor-Authentifizierung als Managed Lösung schon seit 10 Jahren im Betrieb. Früher auf Basis RSA SecurID, mittlerweile (weil RSA sich hat Hacken lassen...) auf Basis OATH für Authentifizierungszwecke.
Und weil wir 2-Faktor-Authentifizierung schon so lange leben, sehen wir das auch als den besseren Standard wenn es um Türöffnung usw. geht.
... bisher bin ich mal sehr zufrieden mit dem MultiIO und werde mir sicher noch ein paar interessante Dinge für den Neubau überlegen, etwa in Bezug auf die Poolsteuerung.
Freut mich, wir sind gespannt und wünschen viel Erfolg.
Natürlich ist die Sensorseite im Webmin nicht als Bedieninterface gedacht, aber eben gerade während der Konfiguration
muss man schnell auch mal was testen. Die Reihenfolge der 3 IOs habe ich durch Drahtbrücken geprüft, aber das war
relativ umständlich, weil man oft 2-3x den Frame umständlich neu laden musste.
Oder eben für die Ausgänge wollte ich beim Test das nicht in die Visu auch noch intergrieren.
Bezüglich Pullup hatte ich mir schon gedacht, dass da ein interner enthalten ist, eigentlich wollte ich 10K nehmen, keine Ahnung warum ich dann am ende auf 1K gekommen bin
Danke für die Info mit dem direkt anlegen der 24V, das hatte ich mich nicht getraut, und die knapp 50 Cent für den Eingangsschutz tun mir hier nicht weh.
Sicherheit:
Die Idee für eine 2-Faktor Authentifizierung ist gut gemeint, aber praktisch natürlich auch etwas kontraproduktiv, wenn ich hier für die Türöffnung gleichzeitig eine Ansteuerung via KNX und 1-wire mache.
Man muss natürlich hier klar definieren, welche Anforderungen hier sind, in meinem Fall wären das:
1.) Umschaltung Tag/Nacht-Modus - im Tagmodus verriegelt die Türe nicht
=> erfolgt im Moment über einen mechanischen Schalter neben der Türe
2.) Türöffnung via Fingerprint
=> erfolgt im Moment direkt vom ekey
3.) Türöffnung via Klingelanlage
=> im Moment nicht implementiert, würde aber via TwinBus erfolgen
Für die reine Zeitsteuerung der Zutrittsberechtigungen könnte ich natürlich das durch Serienschaltung vom internen Relais ekey (überprüft den Finger) und z.B. dem MultiIO (deaktiviert den Zugang zu bestimmten Zeiten).
Bei 1+3 könnte ich natürlich hier einfach ein 2. Relais via KNX steuern und das z.B. bei Abwesenheit in einen Lock-Modus versetzen, aber im Normalbetrieb hier 2 Systeme drücken, damit die Türe aufgeht ist unpraktisch.
Aber natürlich auch ein gewisses Sicherheitsrisiko, dem stimme ich voll zu und deswegen auch meine Bedenken.
Werde die nächsten Tage das mal fertig umsetzen und live testen, bisher bin ich mal sehr zufrieden mit dem MultiIO und
werde mir sicher noch ein paar interessante Dinge für den Neubau überlegen, etwa in Bezug auf die Poolsteuerung.
Doch irgendwie kann man den Ausgang im Webmin nicht ändern (oder ich hab es nicht gefunden),
Richtig, funktioniert (noch) nicht weil nicht dafür vorgesehen.
Im Detail: Die Seite "Sensor Konfig" im Webmin dient im Wesentlichen zur Konfiguration, Namensvergabe, GA und zeitliche Parameter.
Diese Seite war nicht zum Bedienen / Auslesen der Echtzeitstati von IOs vorgesehen. Daher ist eine solche Funktion bisher nicht implementiert.
Wir haben durch diesen Beta-Test verstanden, dass dies jedoch gewünscht wird und denken über eine entsprechende Umsetzung nach, bis dahin bitte OWFS uncached benutzen.
Die Variante mit der Zustandserkennung hab ich noch nicht am Wiregate getestet, weil ich mir nicht sicher bin, ob ich hier den Pullup-Widerstand brauche.
Du bräuchtest keinen Pull-Up Widerstand, weil ein solcher mit 47 kOhm gegen 5 V bereits auf der Multi-IO enthalten ist.
Anmerkung 1 (zum PullUp in Deiner Zeichnung): Der von Dir in der Zeichnung vorgesehene PullUp mit 1 kOhm würde an den 5 V bei durchgeschaltetem Optokoppler zu einem Strom von 5 mA führen.
Das wäre im Falle einer parasitärer Versorgung nur für den einen Kontakt etwa Faktor 5 - 10 zuviel und selbst bei Versorgung durch den Busmaster (der etwa 45 mA liefern kann, bereits 1/9 des zur Verfügung stehenden Stromes).
Der auf dem Multi-IO verbaute Pullup hat 47 kOhm, damit fließen nur 100 uA.
Einen eigenen parallelen PullUp darf man u.U. trotzdem anschließen und dies wäre sogar hilfreich im Falle von Leckströmen in dem Bereich > 20-50 uA, jedoch müssten es nicht gleich 5 mA sein.
Anmerkung 2 (zum Optokoppler zur Trennung vom "Zustandsausgang"): Der IO-Baustein auf dem Multi-IO verträgt Spannungen bis 28 V. Daher dürfte man auch solche 24 V Signale direkt anlegen und man könnte sogar auf den Optokoppler verzichten.
GGfls. wäre hier ein Pullup gegenüber den 24 V mit einigen 10 kOhm sinnvoll, der dann vom dem Ausgang des Türschlosses auf Masse gezogen wird. GND von der Türschloss-Steuerung wäre mit GND des IO auf dem Multi-IO zu verbinden. (Hinweis: Der auf dem Multi-IO befindliche 47 k Pullup auf 5 V ist noch über eine Diode geführt, daher würde eine am Port höhere Spannung - hier 24 V - nicht auf die 5 V Rail durchschlagen - daran haben wir extra gedacht).
Nachteil ist hier, dass die GND zu verbinden wären und bei Unsauberkeiten parasitäre Ströme fließen könnten, so dass die Trennung per Optokoppler die sauberere Lösung ist.
Fraglich ist natürlich wie sicher das ganze ist, weniger wegen Hack-Angriffen, sondern eher wegen Fehlfunktionen am 1-Wire-Bus, sowas wie Fehlauslösungen der Ausgänge. Gibt es da Erfahrungswerte?
Nun, weder unsere Soft- noch unsere Hardware wurde in entsprechenden Dauerversuchen hinsichtlich "Fehlschaltungen" überprüft und auch nicht vom VdS zertifiziert.
Aus grundsätzlichen Erwägungen raten wir davon ab, Sicherheitsfunktionen - und die Öffnung der Haustüre gehört dazu - alleine über komplexe technische Systeme mit vielen Bestandteilen zu steuern. Jedes Bussystem ist hierbei als technisch komplex zu betrachten. Egal ob 1-Wire, KNX, LON oder CAN. Insbesondere wenn dann noch der Nutzer mit selbstgeschriebener Logik eingreift.
Darum raten wir hinsichtlich Öffnung von Haustüren, dies grundsätzlich nur über zwei separate Systeme vorzunehmen, die elektromechanisch gegeneinander verriegelt sind.
Also nehmen wir zwei Relais, die unabhängig gesteuert sind (das eine via Bus, das zweite autark) und deren Kontakte seriell zueinander verdrahtet sind, so dass nur das zusammenwirken beider zur Betätigung des Motorschlosses führt.
Das autarke System könnte z.B. eine Code-Tastatur mit Relais-Ausgang sein, die über den Bus gesteuerte Freigabelogik könnte mit iButton, Fingerprint, RFID usw. realisiert sein. Damit hätte man auch eine einfache Form des Loggings.
Somit: Nur wer den richtigen iButton / Finger / RFID dabei hat und den Code für die Tastatur kennt (Zwei-Faktor-Authentifizierung) wird eine Freigabe durch beide unabhängige Systeme erhalten und damit die Öffnung durch das Motorschloss bewirken.
Dies würde ich für hinreichend sicher halten hinsichtlich Manipulation, Fehlöffnung und Diebstahl von Token (RFID, iButton usw.). Trotzdem daran denken, solcherlei Öffnungssysteme der Versicherung vorher mitzuteilen.
So, heute konnte ich endlich den Versuchsaufbau für meinen I/O-Test abschliessen.
Aufgabenstellung:
Ich setze ein Motorschloss von KFV ein, bei dem folgende Funktionen zur Verfügung stehen:
Umschaltung TAG/NACHT durch Verbinden der Anschlüsse 0/1
Türöffnung durch Anlegen von 24V für 1s an Anschluss 4
Zustandsauswertung (offen/geschlossen) - Anschluss 7 auf Masse
Nachdem das System mit 24V arbeitet habe ich mich entschlossen das ganze mit Optokoppler und Relais abzusichern.
Umsetzung:
Als Basis diente die Relaisschaltung K1 von Pollin, doch konnte ich den dort verwendeten Optokoppler SFH617 hier in Salzburg nicht auftreiben, deshalb verwendete ich den ähnlichen 4N28 (der einzige lagernde).
Das Relais hatte ich im Fundus und stammt ebenfalls von Pollin, dieses ist für 24V und braucht dank des Spulenwiderstands von 2900 Ohm gerade mal 10mA. Die Widerstände mit 1K bzw. 10K sind grobe Schätzungen.
Erst habe ich die Schaltung als eigenständigen Versuchsaufbau getestet mittels Taster und LED, dann habe ich das ganze auf den Ausgang eines Multi-IO gehängt und wollte es testen.
Doch irgendwie kann man den Ausgang im Webmin nicht ändern (oder ich hab es nicht gefunden), aber zum Glück hab ich mich an die Fehlersuche erinnert und den Link zum "uncached", und dort kann man den Eingang schalten. Die Geschwindigkeit ist wirklich gut, es gibt kaum eine Verzögerung beim Ausgang.
Die Variante mit der Zustandserkennung hab ich noch nicht am Wiregate getestet, weil ich mir nicht sicher bin, ob ich hier den Pullup-Widerstand brauche.
Also theoretisch hat zumindest der Teil "schalten" schon mal funktioniert, den Teil auswerten muss ich noch testen.
Sobald das abgeschlossen ist geht das ganze live, damit kann ich dann via VISU zwischen TAG/NACHT umschalten, die Türe öffnen und auswerten, ob die Türe offen oder zu ist.
Fraglich ist natürlich wie sicher das ganze ist, weniger wegen Hack-Angriffen, sondern eher wegen Fehlfunktionen am 1-Wire-Bus, sowas wie Fehlauslösungen der Ausgänge. Gibt es da Erfahrungswerte?
Anbei mein Schaltplan.
@Stefan: Kannst Du bitte einen Blick drauf werfen ob da was falsch dran ist und wie das mit dem Pullup ist - danke
Stefan, du setzt die Leitung als idealen Kondensator an, was mir gewagt erscheint.
Mir fehlt in deiner Rechnung die Leitungsinduktivität, die bei dieser Betrachtung nicht vernachlässigbar ist. Für Leiterbahnen setzt man i.d.R. 1 nH/cm an, bei 20m hin und 20m zurück ergeben sich also gesamt 40nH. Mit der Kapazität zusammen gibt das einen netten Tiefpass, der den Anstieg begrenzen dürfte.
Auch der Ohmsche Widerstand ist bei den von dir berechneten Strömen nicht unerheblich.
Für eine saubere Betrachtung müsste man wohl (ich bin kein HFler, nur E-Technik-Ingenieur, der mit gelegentlich zappelnder Gleichspannung zu tun hat) die Leitung rechnerisch in kleine Abschnitte aus R,L,C zerlegen, diese Elemente dann in Serie schalten und über das Ergebnis dann eine Grenzwertbetrachtung machen (unendlich große Zahl unendlich kurzer Abschnitte). Dafür fehlt mir aber Zeit und Motivation - mein einziger Fensterkontakt hat 20 cm Zuleitung und funktioniert nicht.
Verhandelbar ist die IO's (so wie seit PL35 die Temp/rF) dynamisch zu aktualisieren
Ah, jetzt weiß ich was Du mit Ajax bei PL35 gemeint hast! Ich hatte gedacht das bezieht sich auf die ganze Seite - bei meinem fliegenden Testaufbau hängt halt grad' kein Tempsensor dran.
Verhandlung für die dynamische Aktualisierung? Beim nächsten Franken-Stammtisch zahl ich zwei Deiner Weizen? Oder bringe Dir eine leckere Zigarre für Deinen WireGate Humidor mit?
Das sortieren ist schon gelöst (fehlte einfach nur eine class in der Tabelle, als die IO eingebaut wurden hatte die keiner auser mir + 2 user..)
Speichern der sortierung: (das passiert ja im client): nö ist mir gefühlt zu aufwändig für den Zweck, jeder geht da gefühlt 1-3x im leben hin und stellts 1x ein, fertig, oder?
Verhandelbar ist die IO's (so wie seit PL35 die Temp/rF) dynamisch zu aktualisieren
Wollen wir nicht doch mal wieder so langsam zur Technik zurück kommen ? Finde ich viel spannender
Kein Problem - schieß los
Zur Technik: Grad erst nach Lesen der Hilfe aufgefallen: Man kann ja bei den anderen Sensoren mit Mausklick auf den Spaltenkopf die entsprechende Spalte sortieren. Das geht beim Multi-IO noch nicht.
Allgemein wärs aber cool, wenn man a) mit einem anderen Mauszeiger drauf aufmerksam gemacht würde, dass man den Spaltenkopf anklicken kann und b) wenn die Sortierung den Refresh überleben würde. Aber das ist Kategorie "nice to have".
Hmpf, jetzt war ich's schon wieder
Ich finde Deine Erklärungen - sowohl die technischen als auch die betriebswirtschaftlichen - übrigens sehr spannend! Klar: Wenn die in 500er "Päckchen" gekauften Schraubenzieher weniger kosten als die Supportkosten, dann geht das gut auf. Wobei das auch wieder zeigt, wie gut Euer Support ist - denn bei anderen Unternehmen können Kunden die mit Schraubenziehern Klemmenkiller spielen absolut nicht mit Kulanz rechnen... und mit kostenlosen Schraubenziehern auch nicht.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: