Ultralangsames Bussystem gesucht

[Fritzler]

@ Fritzler: Der M-Bus klingt erstmal super, aber das klappt ja mit den in Wiki genannten ICs nicht so wie mit den 1-Wire Versionen wie ich es im Anfangsbeitrag geschrieben habe. Da bräuchte ich ja immernoch eine Logik hinter den Kommunnikations-ICs. Dann kann ich das doch gleich mit einem Attiny machen oder? Außer dass der M-Bus wesentlich höhere Pegel benutzt.

@Fritzler: Warum der Neustart? Wegen dem Gedanken, dass ich nie irgendwelche Adressräume überfluten kann. Ich will es ja Wartungsfrei haben. Vielleicht ist das auch übertrieben mit dem neustart.
Wie sollen alle ALIVE senden? Gleichzeitig ist ja schlecht. Dann müsste das ALIVE ja auch zeitversetzt sein und dann nachher jede Tür einzeln antworten oder wie soll ich das verstehen?
Master sendet Signal "Neuer Abtastzyklus" => Alle 25 türen senden ALIVE: Also Tür1 nach 5ms für 5ms LOW, tür 2 nach weiteren 5ms warten 5ms LOW und so weiter. Nachdem alle 25 geantwortet haben soll dann wohl Tür 1 das "offen/geschlossen" Signal senden und dann Tür 2 oder wie soll ich das verstehen?

Ja der M-Bus braucht 2 Leitungen, aber bringt eben seine eigene Betriebsspannung mit.
Daher entfällt der die Versorgungsleitung und du müsstest 2 somit 2 frei haben.
Türlich brauchte nochn AVR hinter dem M-Bus Phy IC, M-Bus ist eigentlich nur nen modulierter UART.
Der Kommunikations IC hat aber schon etwas Schutzschaltung welcher den AVR vom Gubbel auf dem Bus fernehält.

Wie gesagt 2 Startsignale nach länge codiert.
Sagen wir mal:
100ms low als start -> Normale Tür zu/auf Abfragen
200ms low als start -> lebt ihr noch?

Die Slaves antworten immmer nach demselben Schema, der Master weis ja was er getriggert hat.
Also was ich oben schrieb: Tür 1 zieht nach 10ms für 5ms auf LOW; Tür 2 nach weiteren 10ms für 5ms auf low.

[Jch]

Ich glaube ich nutze die Mikrocontrollerversion. Mit NANDs habe ich noch nie gearbeitet. Da will ich mich glaube ich nicht mehr reindenken.
Aber den Bauernbus mit Microslotting könnte ich mir vorstellen zu realisieren.

Das Thema muss ich eh nächste Woche mal mit dem Chef besprechen, da es doch zeitintensiver wird als ursprünglich gedacht.

Jetzt steht noch die Frage im Raum warum strom- und nicht spannungsgesteuert?

[berlinerbaer]

Die Zabex'sche Lösung halte ich auch für eine gute Idee.

Alternativ dazu, dafür eine Platine zu produzieren, würde ich fertige Digispark ATTiny85-Module fürn Euro das Stück kaufen.
Billiger kriegt man das selber nicht hin...
Arduino-Code ist übersichtlich und die Dinger haben vUSB eingebaut, kein Gefummel mit USB-seriell-Adaptern.

Die restlichen Komponenten kann man frei oder auf Lochraster verdrahten und das Ganze dann vergießen.
Die Türadressen werden einprogrammiert und auf das Gehäuse geschrieben.

Damit wäre das Ganze flott und preiswert zusammenzubauen und absolut wetterfest.
Wenn man sich ein paar Module davon auf Halde legt, ist auch für Ersatz- und Neutür-Bedarf gesorgt.

[Bumbum]

...da habe ich ja was losgetreten mit meiner Busidee. Ich finds toll, was sich hier daraus entwickelt und das ganze dermaßen professionel angegangen wird. Ich bin auf das Ergebnis gespannt!

Viele Grüße,
Andreas

[ferdimh]

Können wir das Problem nicht auch im Frequenzbereich lösen?
Über jeden Schalter wird ein Minimalschwinger (1 Transistor+RCRCRC oder so, ~1V Verlust?) geklemmt - Speisung mit Stromquelle.
Die Frequenzen werden strategisch so gewählt, dass man das in der Regel ausknobeln kann. (Evtl ein Array NE567). Wenn es bei N offenen Türen irgendwo einen zusätzlichen Fehlalarm gibt, bringt das ziemlich sicher keinen um.
Wichtig ist, dass die Tatsache, dass noch Türen offen sind, immer noch zuverlässig erkannt wird, wenn der Rest versagt, ist es zwar ärgerlich, aber kein Drama.

[shaun]

Die von Fritzler für M-Bus genannten PHY-Chips sind immer nur für die Slaves, also die 20-25 Türsensoren. EInen Controller braucht es natürlich dazu, aber dafür gibt es genug Schaltbeispiele. Jeder M-Bus Slave darf sich ohne weiteres Nachdenken 1,5mA aus dem Bus ziehen, mit einem entsprechend langsamen Controller braucht es also ggf nicht mal einen Step-Down, da reicht dann ein Längsregler.

Master-seitig muss man immer selbst tätig werden. Der Master muss 36V bereitstellen und kurzschlussfest sein, ausserdem den Strom messen können und schnelle Änderungen von 6...8mA erkennen, weil das die "Marks" vom Slave sind. Selbst sendet er indem er die Bus-Spannung um 12V absenkt.
Ich habe letztes Jahr einen Master gebaut, der ein Rudel Wärmemengen-, Wasser- und Stromzähler abfragt (Erdwärmeanlagen), es gibt zwar für <50 EUR (wimre) ein fertiges Modul, das mit 5 oder 12v gefüttert wird und Statussignale + Rx/Tx zum UART bereitstellt und die gesamte Stromüberwachung und Spannungserzeugung erledigt, aber das kann dann ja jeder - nein, ich wollte mich nur nicht von dem Hersteller abhängig machen.

[sukram]

Und wie wäre es, wenn man die ganze Schleife als 20mA Loop betrachtet? Und jeder Controller, der eine offene Tür hat, sendet einen Ton zwischen 1 und 2 kHz alle Sekunde auf die Schleife?

[Bastelbruder]

Die Idee ist nicht so schlecht. Ausgabe per Lautsprecher an der Zentrale und die Händiäpp "Spectroid" (must have, für umme) gibt die Frequenz aus. Wenn zwei Türsignale sich überschneiden ist das auch nicht schlimm, die Frequenzen müssen bloß 2% auseinanderliegen damit der Spekki die zuverlässig zuordnen kann.

Muß bloß noch Einer die Hardware bauen. Die beworbenen Platinchen mit eingebautem Programmierzwischengesicht (nice to have, aber wozu an jeder Tür?) sind zwar nett, aber die eigentliche Hardware (weiter oben beschrieben) zum Anschluß an die Türschleife fehlt vollständig und muß trotzdem zusammengefrickelt werden.

Die zusätzlich an der Zentrale notwendige Mimik ist primitiv, sie sollte aber die alte Überwachungsmimik nicht völlig unbrauchbar machen. Ob 10 oder 20 mA Schleifenstrom ist egal.

[berlinerbaer]

Mein Chef hat mich gefragt wie man alle Außentürem vom Betrieb auf geschlossenheit überwachen kann und gleichzeitig weiss, welche Tür wie lange offen ist.

Es soll ja auch geloggt werden.
Von daher ist es schon sinnvoll, sich für ein System an den Türen zu entscheiden, das von einem zentalen Mikrocontroller in Computer-verdaulicher Form geloggt werden kann.

Besonders elegant wäre es natürlich, dafür eine Lösung mit Ethernet/WLAN zu nehmen (10 MBit Ethernet-Baustein + Mikro-Controller, ein ESP8266 oder eine Himbeere) und direkt Unix-syslog-Pakete oder SNMP zu basteln. Auf dem server gibt es dann logrotate und diverse Visualisierungsoptionen fix und fertig dazu.

[Bastelbruder]

Die letzgenannte Forderung betrifft wohl doch nur die Zentrale. Ob dort ein Lautsprecher mit Akustik-Spekki werkelt oder zum Schluß eine Himbeere ein FFT-modul laufen hat und dem Scheffe den Türstatus aufs Klo-fone simst ist erst das zweite Problem dieser Mimik.

Problem 1 war und ist die Zweidrahtleitung zu den Türkontakten. Die preiswerteste Hardware wurde beleuchtet. Ob die Tinys jetzt alle Master-Resetgesteuert ihre Zeit absondern oder ob auch noch der Takt vom Master übertragen wird oder ob zufällig irgendwelche Frequenzen gesendet werden, die an den Türen erforderliche Hardware ist exakt identisch. Minimaler als Tiny plus 7 Bauteile gehts kaum.

[Toddybaer]

2 Drähte....

schonmal an KNX gedacht? Mit Digitaleingängen die Türen erfassen und am zentrahlen Display oder über den Server auswerten

Gut, billig ist was anderes...
Aber vielleicht ist KNX schon im Gebäude vorhanden?

[Zabex]

Ich habe da mal was zusammengestellt.
Einen Schaltplan habe ich in LTSpice simuliert. Hier mal mit ein paar Erklärungen

Die Spannungen für den Komparator für die Simulation eines Porteingangs habe ich nachträglich von +/-10V auf +5/0V geändert.
Etwaige notwendige Suppressordioden sind nicht eingezeichnet. Die Spulen sollen die Leitung simulieren.

Das Simulationsergebnis sieht dann so aus:


Exemplarisch habe ich Software für einen Master und die vielen Slaves mit der Arduino-IDE erstellt. Das ganze Paket mit Quellcode, Screenshots und LTSpice-Dateien gibt es als ZIP-Datei hier:
LangsamerBus.zip

Die Software erzeugt im Master nach längerer Pause einen Startpuls, die Slaves antworten nach einer Verzögerungszeit, die ihrer Adresse entspricht. Die Antwort besteht aus einem kurzen oder langen Puls.

Nähere Erklärungen stehen als Kommentar im Quellcode.

Im Master habe ich die Ausgabe mal für ein Rudel Neopixel programmiert. Dazu müssen 25 Neopixel angeschlossen werden, die permanent den Türzustand anzeigen. Rot=Tür offen, Grün=Tür zu, Gelb=Slave hat nicht geantwortet.

Als Slave-Hardware würde ich die Digispark Module mit AtTiny85 Prozessor und 78V05 Längsregler empfehlen.

Wenn man die evtl. im eingebauten Zustand flashen will, sollte man die Version mit USB-Micro Buchse wählen:


Die Module gibt's für unter 2€ beim Chinesen.

Als Neopixel könnte man 4 Streifen mit je 8 Leds verbauen (spart Verdrahtung), oder einzelne Pixel z.B. hinter einen Gebäudeplan kleben, so dass eine Zuordnung von LED und Tür sofort ersichtlich ist.


Gruß,
Zabex

P.S.:Hat Spaß gemacht, mal wieder was sinnvolles zu programmieren

[Chemnitzsurfer]

Oder mal ganz anders gedacht, über die bestehende Leitung kommt nur der Strom , das Signal geht dann via 433MHz oder so über Funk zurück. Alarmanlagen mit Funktürkontakten gibt es inzwischen einige. 50-100m ollte man schon überbrückt bekommen, solange man nicht den EMV Supergau hat.

https://www.ebay.de/itm/5-x-Funk-Tuerko ... 2022906105
https://www.ebay.de/itm/4-x-Funk-Tuerko ... 5731.m3795
https://www.ebay.de/itm/4-x-Funk-Fenste ... 5731.m3795
brauchst dann halt nur was SDR mäßiges zur Auswertung oder eine (gebrauchte) Alarmzentrale

[Bastelbruder]

Eins hab ich noch nicht gespannt: Woher werden die slaves versorgt?

[berlinerbaer]

Wow, das ist doch mal full service, man stellt eine exotische Frage und bekommt ein perfektes, kosteneffektives System fertigentwickelt.
Für die komplette hardware sollte man mit einem zweistelligen Eurobetrag hinkommen, denn die Kabel liegen ja schon.

Ich würde allerdings beim Digispark den pin 1 meiden, weil da die onboard-LED dranhängt.
Den könnte man stattdessen beim senden/empfangen als Funktions-Indikator oder zum Türadressen-rausmorsen verwenden, damit man das ohne neuflashen feststellen kann, wenn einem die mal durcheinanderkommen.
Oder auch beides: Beim starten blinkt er erst die Zehnerstellen raus, kurze Pause, Einer-Stellen, längere Pause und dann blinkt er synchron mit den empfangenen und gesendeten Impulsen.

Die "Neopixel" gibt es beim Chinesen auch super-billig schon fix und fertig auf einzelnen kleinen Platinchen zum Verlöten hinterm Gebäudeplan.

Gegeben ist ja eine Verkabelung 3xNYM, also kriegen die Türmodule ihren Strom von zwei Adern und auf der dritten laufen die Daten.

[Nilsen]

Kenne hier den Betreiber eines sehr langsamen Bus-Systems...

https://www.vgn.de

Vielleicht kann der weiterhelfen...

[Jch]

... es gibt zwar für <50 EUR (wimre) ein fertiges Modul, das mit 5 oder 12v gefüttert wird und Statussignale + Rx/Tx zum UART bereitstellt und die gesamte Stromüberwachung und Spannungserzeugung erledigt, aber das kann dann ja jeder - nein, ich wollte mich nur nicht von dem Hersteller abhängig machen.

Ich wäre zu faul sowas selber zu bauen und wäre an dem Gerät interessiert. Wo finde ich dieses?

Mein Chef hat mich gefragt wie man alle Außentürem vom Betrieb auf geschlossenheit überwachen kann und gleichzeitig weiss, welche Tür wie lange offen ist.

Es soll ja auch geloggt werden.
Von daher ist es schon sinnvoll, sich für ein System an den Türen zu entscheiden, das von einem zentalen Mikrocontroller in Computer-verdaulicher Form geloggt werden kann.

Besonders elegant wäre es natürlich, dafür eine Lösung mit Ethernet/WLAN zu nehmen (10 MBit Ethernet-Baustein + Mikro-Controller, ein ESP8266 oder eine Himbeere) und direkt Unix-syslog-Pakete oder SNMP zu basteln. Auf dem server gibt es dann logrotate und diverse Visualisierungsoptionen fix und fertig dazu.

Mein Gedanke war, dass ein Arduino der Master ist und die Werte per UART an einen RasPi weitergibt. Die Programmierung des RasPis ist nicht meine Aufgabe, dazu gibt es einen Softwaremenschen in der Firma, welche die Daten entweder an einem Monitor oder per Push-Service weitergibt. Wie der Chef/Hausmeister/Spätschichtmitarbeiter die Infos über den Türzustand haben will und/oder bekommen kann ist nicht meine Aufgabe. Dies muss erst noch ausdiskutiert werden und z.B. die Himbeere übernehmen. Ich muss nur der Himbeere die Info über die offenen Türen geben.

2 Drähte....

schonmal an KNX gedacht? Mit Digitaleingängen die Türen erfassen und am zentrahlen Display oder über den Server auswerten

Gut, billig ist was anderes...
Aber vielleicht ist KNX schon im Gebäude vorhanden?

KNX ist mEn nicht im Gebäude vorhanden und die verlangen doch auch mindestens eine gezwirbelte Leitung. Und gibt es buspowered Slaves in Zigarettenschachtelgröße, welche in die Türen passen?


Die Zabex'sche Lösung ist sehr geil geworden. Nur muss ich dafür ernsthaft abchecken ob ich überall die dritte Ader zur Verfügung habe. Das kann ein bisschen dauern, da dieses Türprojekt für mich Prio D-Z hat und ich mich dem Projet somit nur sporadisch widmen kann.

@ Chenitzsurfer, von Funk halte ich nichts, da das Gebäufe funktechnisch eine Katastrophe ist. Dicke Mauern, viele Stahl-Brandschutztüren, viele Funkquellen im Gebäude (WLAN, DECT, und vieles mit HF; ja, ist alles mehr als die 433MHz, aber das ist mir zu unsicher)

Eins hab ich noch nicht gespannt: Woher werden die slaves versorgt?

Wenn ich wirklich 3 Adern nutzen kann, dann werden 2 für die Spannungsversorgung genutzt und die 3. ist die Datenleitung. Wenn ich nur 2 Adern zur verfügung habe, dann muss es wohl Buspowered werden.

Wow, das ist doch mal full service, man stellt eine exotische Frage und bekommt ein perfektes, kosteneffektives System fertigentwickelt.

Jo, das habe ich mir auch gedacht.

Kenne hier den Betreiber eines sehr langsamen Bus-Systems...

https://www.vgn.de

Vielleicht kann der weiterhelfen...

Nilsen, ist zwar nett gemeint, aber soviel Zeit hat der Chef dann auch wieder nicht um auf die Verspätungen der Türen zu warten.

[berlinerbaer]

Die Zabex'sche Lösung ist sehr geil geworden. Nur muss ich dafür ernsthaft abchecken ob ich überall die dritte Ader zur Verfügung habe. Das kann ein bisschen dauern, da dieses Türprojekt für mich Prio D-Z hat und ich mich dem Projet somit nur sporadisch widmen kann.

Wenn Du das Zabexsche System beibehalten willst, musst Du halt in jedes Modul noch einen kleinen Goldcap packen und mit Dioden daran hindern, in den Bus zurückzuspeisen. Dann schaltet der Controller regelmäßig den Strom ab und die Türmodule melden sich, vom Goldcap mit Strom versorgt, der Reihe nach.

Ist wahrscheinlich kosteneffektiver, als sich auf die Jagd nach der/den Unterbrechungen in der dritten Ader zu machen. Mal schnell gucken, ob sie Durchgang hat, kann ja nicht so aufwendig sein, aber dann weißt Du, was eventuell noch mit auf die Stückliste für die Module muss.

Wenn ihr euch in den ersten paar Wochen mal die Tür-Bewegungsdaten aus der Nähe anschaut, werdet ihr vermutlich überraschende Dinge entdecken. Wahrscheinlich wäre es diplomatisch klug, den Betriebsrat über die Einrichtung des Systems zu informieren.
Und natürlich das Einverständnis zur Datenerhebung bei den Türen einholen. Gerade Hintertüren können da sehr eigen sein .

[sysconsol]

Bevor man Goldcaps irgendwo einbaut, bitte die Datenblätter dazu lesen.
Erfahrungsgemäß leben die Goldcaps nicht so lange, wie das oft angepriesen wird.
Dann ist wieder Wartung angesagt.

[2moose]

Bei meinem AV-Receiver hab ich die Goldcapanschlüsse hinterm Display aus dem Gehäuse rausgeführt, für den schnellen Wechsel. Es wird aber sicher elegantere Möglichkeiten wie eine Schutzschaltung geben.

[Zabex]

Wenn nur 2 Adern zur Verfügung stehen und man auf Buspowered geht, wird die Schaltungsauslegung erheblich komplexer.
Auch sollte man dann nicht mit gemischter Puls-Positions und Puls-Längen Codierung, sondern ausschließlich mit Puls-Positions Codierung arbeiten.
Beispiel:
Periodendauer 40ms. Slave- Adresse ist also 40ms * Türnummer.
Geschlossene Tür: Slave zieht am Anfang seines Zeitschlitzes den Bus für 10ms runter
Offene Tür: Slave zieht nach 20ms seines Zeitschlitz-Anfangs den Bus für 10ms runter
Ich habe mal eine Probeschaltung in LTSpice zusammengeklickt. Je Slave eine Diode auf 47uF Elko und mit 6mA Stromsenke belastet. 6mA für ca. 1mA mittlere AtTiny85 Versorgung und 5mA 78L05 Querstrom (ist in der Regel nur 3mA). Davon 25 Baugruppen jeweils mit einer 16mH Spule verbunden. Bus-Einspeisung: 12V über 27R Widerstand.
LTSpice rechnet seit etwa 9Uhr am ersten Puls (i5 mit 3.6GHz). Die üblichen .options sind bereits auf "Speed statt Präzision" eingestellt. Schafft momentan zwischn 50..100ns Simulationszeit pro Sekunde.
Heute Mittag werde ich das Ergebnis mal posten, wenn die 5 zu berechnenden Pulse dann durch sind.

Alternativlösung mit 2 Adern: Nutze die Adern für Masse und Bus. Die 5V Versorgung dezentral an jeder Tür.


Gruß,
Zabex

[Zabex]

Bilder

Die gesamte Schaltung (war ein Versuch; leider komplett unleserlich):


Also einzelne Details:

Buseinspeisung und erster Slave mit 6ms Pulserzeugung:


Ein Slave mit 10ms Pulserzeugung weiter hinten:

[E_Tobi]

Versehe die Ls mal mit kleinen AC-Verlusten (=>Rpar), das dürfte die Simulationszeit deutlich senken, wenn dus noch nicht getan hast.

[ferdimh]

Mir erscheinen 16mH auch reichlich viel für diese Leitung...

[sysconsol]

Die Leitung ist ein 3x1,5qmm NYM. also weder geschirmt noch verdrillt.

[Bastelbruder]

Vielleicht sollte man eine verlustbehaftete Zweidrahtleitung "O. Lossy Transmission Line" in die Simulation einbauen.
Mit den Parametern hab' ich mich aber auch noch nicht beschäftigt. Die Erinnerung meint daß ein Z von 100 Ohm passen dürfte, in der Funkschau war mal ein Arme-Leute-Dummy aus NYM beschrieben.

[ferdimh]

Hier wäre die Frage zu klären, ob der Rückleiter im gleichen Kabel liegt, oder ob das wirklich eine Schleife ist.
Im letzteren Fall ist die Induktivität das bessere Modell (ich würde sie aber eine Zehnerpotenz kleiner schätzen), im anderen Fall wäre die gedachte Induktivität deutlich geringer und die Leitung das bessere Modell.

[Bastelbruder]

Wenn's eine Schleife wäre, dann hätte sich das Thema bereits erledigt. Dann würde selbst die von mir vorgeschlagene Hardware keinen Sommer überleben. Auch nicht mit zusätzlichen Drosseln und Gasentladungs-Ableitern.

[Zabex]

Ich gehe auch davon aus, dass die wahre Induktivität deutlich geringer ist. Aber den Worst-Case rechnen ist ja auch nicht ganz verkehrt wenn man keine echten Daten hat.
Hier das Simulationsergebnis. Wie vermutet, gibt es deutliche Pulsverschiebungen zwischen Leitungsanfang und Ende durch die Induktivitäten (rotes und blaues Signal).


Ich lass das jetzt noch mal mit kürzeren Pulsen und 3 Pulsquellen rechnen.

[Bastelbruder]

Probier mal mit nicht so harten Impulsen sondern mit Kilohertz-Bursts die über ein RC-Glied 100 Ohm 100 nF eingespeist werden. Da ist zwar auf der Empfangsseite der Aufwand geringfügig höher, aber durch den kontrollierten Abschluß nur im Sendefall (standby = tristate) wird da allerlei phasenverschobener Blödsinn stark gedämpft. Und die eingesparten Bauteile um den bislang noch völlig ungeschützten Transistor könnte man durch eine Transildiode sinnvoll ersetzen.
Vielleicht mal nach der Beschaltung eines ThickEthernet transceivers suchen.

[Zabex]

Den Spulen 1M parallel und 0.1R Serienwiderstand zu geben hat die Simulation erheblich beschleunigt! Dauert jetzt unter 2s für 500ms Simulationszeit.
Das Ergebnis für 5ms Pulse sieht schon ganz brauchbar aus:



Man käme mit 40ms Zeitschlitz-Abstand und 5ms Pulsen hin.

[Nilsen]

Verdammt, jetzt hab ich auch mein Entwicklerhirn angeschmissen! Das passiert irgend wie automatisch. Kennt jemand ein Mittel dagegen?

Wenn du eine Reihenschaltung von Sensoren (Türwächtern) hast, schreit das eigentlich schon nach einer Stromschleife. Hier währen 4-20mA sinnvoll. Im Standby würde ich 20mA fließen lassen, damit kannst du gleich die Versorgung der Einzelsensoren erschlagen. Damit bei der Menge der in Reihe geschalteten Sensoren die Speisende Spannung nicht so hoch wird, würde ich dann einen LTC3105 an einer Diode langsam die Energie aus dem System nuckeln lassen (siehe Applikation Note, Current Loop Power Tap). So hast du je Sensor maximal 1V Spannungsabfall. Den Sensoren würde ich dann jeweils einen Controller mit einer eindeutigen Adresse verpassen und einzeln ansprechen. Der jeweils aktive Sensor kann dann die gewünschte Information durch Drosselung des Stromes auf 4mA an den Empfänger Senden. Nacheinander werden alle Sensoren in String abgefragt.

[Zabex]

Eine echte Stromschleife mit Step-Up Wandler drin ist nachrichtentechnisch tatsächlich schön störunanfällig. Allerdings ist der schaltungstechnische Aufwand dafür doch recht hoch und man kann viel falsch machen. Das Gleiche gilt für die Einspeisung einer Frequenz. Jeder Empfänger braucht dann einen Bandpass und einen Detektor - also analog Technik die halbwegs sauber ausgelegt sein muss.
Ich habe versucht, das Ganze so primitiv wie möglich zu machen. Daher im Zweidrahtbetrieb auch die fette 400mA Stromquelle und die (relativ) langen Pulszeiten. Reflektionen laufen sich innerhalb der Pulszeit tot, Störungen werden durch die mehrfache Abfrage in der Software rausgefiltert.
Die Pulse sind einfach zu erzeugen und leicht zu detektieren. Die Schaltung In meiner Simulation ist natürlich kein fertiger Schaltplan. Die Basis des Transistors darf gerne mit 47K gegen Emitter gezogen werden. Über den Transistor gehört eine Suppressordiode (z.B. 15V) und neben den 47uF Elko ein 100nF Kerko. Das ist aber alles recht primitiv gegenüber einer echten Stromschleife.

[Burga]

Würde das nicht auch mit einem durch die Türschalter verstimmbaren Schwingkreis gehen? Also irgendeine bekannte Frequenz drauf geben und die dann mittels L/C gliedern an den Türen verstimmen. Halt ähnlich zu den 21 verschiedenen Widerständen, nur mit sich ändernder Frequenz statt sich ändernden Strom bzw. Spannung.

Dürfte auch etwas störungsunempfindlicher sein, da sich Störungen wohl nur auf die Amplitude auswirken würden. Den Zeitpunkt beim Öffnen oder Schließen einer Tür müsste man sich allerdings noch mal anschauen.

[Jch]

Sooooo. Es geht langsam weiter.

Mein Chef hat mir heute die Schaltung mal gezeigt.

Ein bisschen merkwürdig finde ich das ganze schon. Vielleicht habt Ihr ja wieder ein paar Ideen, was das sein könnte.

Der linke Trafo ist für die Schalter. Mir stellt sich nur die Frage, wofür man da einen 400VA Trafo (mit 4 sekundärabgängen, wovon nur einer benutzt wird)??
Der rechte Trafo ist für die Lampen. 250VA 24V. Komischerweise sind 2*6 Watt, 4,7Ohm parallel als Vorwiderstand (grün) zum Trafo (Primär) drin. Wofür ist diese Heizung da?
Ich kann mir nicht vorstellen, dass man den Schaltkasten im Winter heizen muss um die Funktionalität des Relais zu gewärleisten.

Der Weise Widerstand (15 Ohm) wird nur warm, wenn die Türen geschlossen sind und die Lampen an sind. Aber wofür könnte dieser sein? Spannungsfall von 7V, wenn dieser "AN" ist.
Ich kann mir nicht vorstellen, dass dieser ein Vorwiderstand für das Relais ist. Vorallem da er warm geworden ist, wenn ich die Relaisspule direkt vom Trafo versorgt habe. Könnte das ein Serienwiderstand für die Lampen sein, damit diese nur mit 18V laufen um die Lebensdauer zu verlängern? Oder sonst ein Grund der mir nicht einfallen will.

Der Abgang für die Lampen und Schalter ist ein NYM 5*2,5. Also kann ich an dieser Stelle keine zwei oder mehr Bussysteme (für den alten Teil der Firma und den angebauten Teilen) aufziehen.

[ESDKittel]

Die Trafos waren warscheinlich halt grad da.
Die grünen Widerstände entweder Einschaltstrombegrenzung oder Spannungsanpassung.
Beim weißen tippe ich auch auf Lebensdauerverlängerung der Lampe oder der Relaispule.