Homematic Wired - Homebrew Devices

Thorsten Pferdekaemper · 27 März 2018, 23:32:39

Zitat von: loetmeister am 26 März 2018, 23:12:43Hab den post oben ergänzt, (z.B. --> long_multiexecute: Wiederholte lange Tastendrücke beachten. ja/nein. Bei nein wird nur der erste lange Tastendruck ausgewertet.)
Das bringt mich zum nächsten Problem... um das zu erkennen brauche ich den key press counter im set() bzw. receiveKeyEvent()...

Ich hab mir das mal angeschaut. Da hast Du wohl Recht... Mach mal einen Vorschlag, wie das aussehen könnte.

Zitat von: Ralf9 am 27 März 2018, 22:34:51
Danke für die Erklärungen und Infos ich habe es mir mal in den libs angeschaut.
Demnach können logging/notify events nur verloren gehen, wenn bei einem ausbleibenden ACK und ruhigen Bus 3x erfolglos "probiert" wurde.

Ich nehme an, mit "logging/notify" Eevents meinst Du das, was bei der Änderung eines Ausgangs geschickt wird. Dann hast Du Recht, zumindest wenn man HBWSwitch verwendet. Die Überlegung dabei ist, dass wenn der Bus tatsächlich ruhig ist und die Zentrale nicht antwortet, dann können wir's auch gleich bleiben lassen. Liegt es aber am (temporären?) Traffic auf dem Bus, dann wird bis in alle Ewigkeit wiederholt. Ich finde das im Prinzip so ok, das blockiert auch nicht ganz so schlimm. (Zugegebenermaßen ist etwas unschön, was dann passiert, wenn die Zentrale mal nicht will.)

ZitatWenn ich das richtig überblicke, dann wird bei key events per broadcast und ohne auf ack zu warten gesendet. Das retry wird hier auf denjenigen der den Taster drückt verlagert.

Bei Key Events wird tatsächlich nicht explizit an die Zentrale gesendet. (Ich glaube, das habe ich mir von den Original HMW-Teilen abgeschaut.) Nur bei Peerings wird an die jeweilige Adresse gesendet und dann auch auf ein ACK gewartet. D.h. wenn man mal ein kaputtes gepeertes Device hat wird es auch ein bisschen hässlich, insbesondere, wenn mit mehreren Kanälen gepeert ist (HBW sendet einmal pro Kanal, nicht nur pro Device wie bei HMW).
Tatsächlich geht bei Traffic auf dem Bus der Key Event sofort verloren.

Das mit den Bitpuffern hilft erstmal nur dafür, dass bei Traffic auf dem Bus nichts mehr verloren geht. (Es ist so ähnlich wie das, was in HBWSwitch heute schon passiert.) Allerdings hat man immer noch Blockaden, wenn ACKs auf sich warten lassen. Wenn man das noch "parallelisieren" will, dann müsste man sich noch merken, wo man gerade in der Abarbeitung ist. Wenn man z.B. zwei Taster hat, die jeweils mit vier (ggf. unterschiedlichen oder auch denselben) Kanälen gepeert sind, und beide Taster kurz hintereinander gedrückt werden, dann muss man sich merken, bei welchem Peering zu welchem Taster man gerade ist. (Oder man muss immer alle Peerings in einem Rutsch abarbeiten, aber dann blockiert's halt wieder.)
Außerdem sollte meiner Meinung nach sichergestellt sein, dass die Events zu Tastern immer in der Reihenfolge gesendet werden, in der die Taster auch gedrückt wurden. Das kann relevant sein, wenn z.B. ein Taster Rollläden hochfährt und der andere runter.
Dann ergeben sich darauf aufbauend solche Fragestellungen wie: Was ist, wenn derselbe Taster zweimal kurz hintereinander gedrückt wird und das System mit dem Abarbeiten der Peerings noch nicht fertig ist? Was soll passieren, wenn bei zwei Tastern erst der erste, dann der zweite, dann wieder der erste gedrückt wird und das System nicht hinterherkommt?

Vielleicht müssen wir uns da mal eine Liste machen und einfach mal anfangen, das ganze zu verbessern.

Gruß,
Thorsten

loetmeister · 27 März 2018, 23:53:49

Hallo,

Zitat von: Langerrenner am 27 März 2018, 10:52:08
in der ELV war vor Jahren ein Bericht zu den Aktoren und deren Aktionsprofile. Kennst Du das, wenn nicht habe ich den File angehängt.

Super. Vielen Dank! Kannte ich nicht...
Hatte mir mal https://www.homematic-inside.de/software/download/item/expertenparameter angeschaut. War auch informativ, aber ein Dokument zum nachschlagen ist noch besser

Zitat von: Ralf9 am 27 März 2018, 22:34:51
Demnach können logging/notify events nur verloren gehen, wenn bei einem ausbleibenden ACK und ruhigen Bus 3x erfolglos "probiert" wurde.
Wenn ich das richtig überblicke, dann wird bei key events per broadcast und ohne auf ack zu warten gesendet. Das retry wird hier auf denjenigen der den Taster drückt verlagert.

@loetmeister Du kannst mal testen wie es sich verhält, wenn der HM485d.pl nicht läuft.

Ja, ohne FEHM sehe ich drei Versuche.
Die notify events gehen aber direkt an die Zentrale...

Code Auswählen


T: FD:00:00:00:01:D8:42:00:00:15:05:69:00:C8:3B:F6
T: FD:00:00:00:01:D8:42:00:00:15:05:69:00:C8:3B:F6
T: FD:00:00:00:01:D8:42:00:00:15:05:69:00:C8:3B:F6

Zitat von: Ralf9 am 27 März 2018, 22:34:51
Das ganze gefällt mir nicht so richtig.Ich möchte die Blockierungen beim Senden wegbekommen. Ich weiß inzwischen wie ich es besser hinbekomme.
Es ist dazu keine Sendewarteschlange notwendig.
Es müsste funktionieren, wenn ich die logging/notify events und die key events in jeweils einem eigenen Bitpuffer speichere. Die zugehörigen Infos werden in einem separaten Array gespeichert,
Bei z.B. 16 Eingängen sind es 16 Bit, also 2 byte.
In der loop wird dann, falls der puffer ungleich 0 ist, in einer Schleife geschaut welche Bits im Puffer gesetzt sind. Den gesetzen Bits entsprechenden Eingänge werden dann gesendet.

Das hab ich nicht so ganz Verstanden.... du will die 3 Sendeversuche beim belegten Bus in den loop verlagern, damit "HBWDevice::sendFrame" nicht das Gerät blockiert? Da müsstest du aber nicht nur wissen das noch ein notify event zu senden ist, sondern auch mit welchen daten und den Sende buffer neu schreiben...?

Für den notify Fall (sendInfoMessage) gibt es ja einen neuen Versuch, über nextFeedbackDelay - hier könnte man sendFrame ja mitteilen (per Parameter? - default =3?) nur einen Sendeversuch zu unternehmen... wenn das nicht die Zuverlässigkeit negativ beeinflusst. Aber dann hat man schon mal zwischen den sendInfoMessage Versuchen etwas Zeit was anderes zu machen... "non-blocking" wärs damit noch nicht...

Zitat
@loetmeister
Du verwendest, damit Du mehr Ausgänge bekommst, als Shiftregister 74HC595.
Die geht mit dem MCP23017 einfacher, es gibt dafür eine Lib

Danke. Über I²C ist das natürlich auch chic... Ich teste mal weiter mit den 74HC595, die sind billig und gibts bei Reichelt im SMD Gehäuse. Als DIP Version ist mir das zu groß

Gruß,
Thomas

loetmeister · 30 März 2018, 00:22:29

Moin,

hab mal ein wenig weiter gemacht...
Der Vorschalg long_multiexecute, etc. zu implementieren würde in etwa so ausehen, das ich keyPressNum zu receiveKeyEvent() in HBWLinkReceiver class hinzugefügt habe:
https://github.com/loetmeister/HBWired/commit/0dfb801c744f65bcdf50b9163986b35be134d6ee

Dann habe ich alle Daten in HBWLinkSwitch::receiveKeyEvent zur Verfügung: keyPressNum, actionType und alle EEPROM peering Parameter.

Code Auswählen

  uint8_t data[8];  // store all peer parameter
  uint8_t *pdata = data;
  data[7] = keyPressNum;
  ...
        device->readEEPROM(&data, eepromStart + EEPROM_SIZE * i + 13, 7);     // read all parameters (must be consecutive)
        device->set(targetChannel,8,pdata);    // channel, data length, data

Set() ruft dann die channel set() Funktion auf, in der wird dann ein wenig mehr gemacht als bisher...

Das ließe sich bestimmt was schöner schreiben, grade wenn man das array wieder auseinander nimmt...

Damit habe ich nun HBW-LC-Sw-12 um alle peering Funktionen ergänzt. ~~Minimal und Absolute OFF time verhält sich noch nicht wie erwartet~~. [fixed!] Der Rest läuft aber schon ganz gut.

LONG_MULTIEXECUTE
- yes/no

short/long_ACTION_TYPE hab ich mit folgenden Optionen implementiert, das erübrigt auch "short_toggle_use". Auswahl:
- INACTIVE
- JUMP_TO_TARGET
- TOGGLE_TO_COUNTER
- TOGGLE_INVERS_TO_COUNTER
- TOGGLE

HBW-LC-Sw-12 commit, wer lust hat sich das anzutun

https://github.com/loetmeister/HBWired/tree/a733f5c9d7ffa9ee5b133224e95842d9ad38c71d/HBW-LC-Sw-12

Beitrag zu den peering optionen aktualisiert: https://forum.fhem.de/index.php/topic,22952.msg786308.html#msg786308

Gruß,
Thomas

Ralf9 · 30 März 2018, 12:20:40

Zitat von: Thorsten Pferdekaemper am 27 März 2018, 23:32:39
Das mit den Bitpuffern hilft erstmal nur dafür, dass bei Traffic auf dem Bus nichts mehr verloren geht. (Es ist so ähnlich wie das, was in HBWSwitch heute schon passiert.) Allerdings hat man immer noch Blockaden, wenn ACKs auf sich warten lassen. Wenn man das noch "parallelisieren" will, dann müsste man sich noch merken, wo man gerade in der Abarbeitung ist. Wenn man z.B. zwei Taster hat, die jeweils mit vier (ggf. unterschiedlichen oder auch denselben) Kanälen gepeert sind, und beide Taster kurz hintereinander gedrückt werden, dann muss man sich merken, bei welchem Peering zu welchem Taster man gerade ist.
Dann ergeben sich darauf aufbauend solche Fragestellungen wie: Was ist, wenn derselbe Taster zweimal kurz hintereinander gedrückt wird und das System mit dem Abarbeiten der Peerings noch nicht fertig ist? Was soll passieren, wenn bei zwei Tastern erst der erste, dann der zweite, dann wieder der erste gedrückt wird und das System nicht hinterherkommt?

Stimmt, ich hatte nicht bedacht, daß ein Taster auch mehrere externe peerings haben kann. Da wird das Puffern sehr komplex und aufwendig.
Das mit den Bitpuffern bei den Tastern würde nur funkttionieren, wenn alle peerings intern sind und es kein long_multiexecute gibt.

Ein erster Schritt wäre daß die sendframe Routine blockierungsfrei ist.

Ich habe mir dies ungefähr so vorgestellt:

Die sendframe Routine erledigt nur das Senden:
Nach dem Senden wird der Status auf waitForAck und die Wartezeit gesetzt.
Bei einem busbusy wird Status auf busbusy gesetzt.
Nach dem Senden und einem erhaltenen ack geht der status z.B. auf ready.
Nach dem Senden per broadcast geht der staus sofort auf ready.

In der HBWDevice::loop() wird dann nach einem receive geprüft ob ein ack empfangen wurde.
Ein evtl retry bei fehlendem ack müsste dann auch hier erfolgen.
Und bei einem busbusy müsste dann nach einer Wartezeit das sendframe erneut aufgerufen werden.

Bei einem logging/notify event wird das entsprechende Bit in dem Bitpuffer gesetzt und, wenn der status ready ist wird geschaut ob der Bus frei ist und gesendet.
In der loop wird geschaut ob etwas im bitpuffer ist und dann mit get der aktuelle Status des entsprechenden Ausgangs geholt und versucht zu senden.
Nach dem Senden wird das Bit im Bitpuffer gelöscht.

Wenn das Modul auch Eingänge hat, welche ja per broadcast gesendet werden, dann müssen diese Vorrang vor den logging/notify events haben.
Ein evtl retry eines logging/notify events kann dann abgebrochen werden da es ja noch im Bitpuffer gespeichert ist.

Wenn das Modul auch Eingänge hat ist auch ein internes peering möglich, was die Gefahr von Buskollisionen senkt.

Gruß Ralf

Ralf9 · 30 März 2018, 12:39:40

Zitat von: loetmeister am 27 März 2018, 23:53:49
Über I²C ist das natürlich auch chic... Ich teste mal weiter mit den 74HC595, die sind billig und gibts bei Reichelt im SMD Gehäuse. Als DIP Version ist mir das zu groß

Den MCP23017 habe ich auch in SMD gefunden.

Ich habe bei Dir nicht gefunden wie Du mit einem Tastendruck den Status der Statemaschine durchschaltest.
Z.B. wenn eine ondelay_time definiert ist, dann wechselt bei jedem Tastendruck der Zustand: off - ondelay - on - off ..

Nachtrag:

Mit
SHORT_JT_ON -> "NO_JUMP_IGNORE_COMMAND"
oder
SHORT_JT_ON -> "ON" // verlängern

und

LONG_JT_OFF -> "NO_JUMP_IGNORE_COMMAND"

ist folgendes möglich:
short schaltet nur ein und long schaltet nur aus
Bei der rechten LED ist eine ondelay_time definiert
Am Anfang ist zu erkennen, daß wenn beide LED an sind, ein weiterer Tastendruck ignoriert wird.

https://www.youtube.com/results?search_query=HBW_IO_SW

Gruß Ralf

loetmeister · 30 März 2018, 17:13:03

Hallo Ralf,

Zitat von: Ralf9 am 30 März 2018, 12:39:40
Ich habe bei Dir nicht gefunden wie Du mit einem Tastendruck den Status der Statemaschine durchschaltest.
Z.B. wenn eine ondelay_time definiert ist, dann wechselt bei jedem Tastendruck der Zustand: off - ondelay - on - off ..

Es gibt zwei trigger. Timer läuft und Wartezeit ist vorbei, oder aktueller und neuer Status sind nicht gleich. Wenn ein Tastendruck kommt (und keine absolute Zeit läuft) dann wird eine Änderung erzwungen:
nextState = FORCE_STATE_CHANGE; // force update
Damit lassen sich on/off delay Zeiten überspringen.

ZitatMit
SHORT_JT_ON -> "NO_JUMP_IGNORE_COMMAND"
oder
SHORT_JT_ON -> "ON" // verlängern

und

LONG_JT_OFF -> "NO_JUMP_IGNORE_COMMAND"

ist folgendes möglich:
short schaltet nur ein und long schaltet nur aus
Bei der rechten LED ist eine ondelay_time definiert
Am Anfang ist zu erkennen, daß wenn beide LED an sind, ein weiterer Tastendruck ignoriert wird.

Das sind zwei Peerings für einen Taster, richtig?
Das klappt bei mir mit SHORT_JT_ON / LONG_JT_OFF -> "NO_JUMP_IGNORE_COMMAND" und einer ondelay_time für einen Ausgang, wie beschrieben.
Bei "SHORT_JT_ON -> "ON" // verlängern" bin ich mir nicht sicher. Meinem Verständnis nach kann ich On/Off delay Zeiten nur überspringen, aber nicht verlängern. Das ginge nur für On/Off Zeiten.

Das Zeit Handling ist noch nicht ganz final...

Minimale Zeit läuft:
* alle neuen Zeiten die kleiner als die aktuelle Restzeit ist werden ignoriert. (auch peerings mit Minimal Zeit nicht in Benutzung (Wert = 0))
-> damit kann ich nur Zeiten verlängern, aber nicht abbrechen...
-> Toggle wird ignoriert, [korrekt?]
-> neue Absolute Zeiten überschreiben den timer, auch mit Zeit == 0. [korrekt?]

Absolute Zeit läuft:
* alle Änderungen (über peerings) werden ignoriert - bis auf neue absolute Zeit, bis der timer abgelaufen ist [korrekt?]
-> eine neue absolute Zeit überschreibt den timer, egal welcher Wert. D.h. eine neue absolute Zeit, bevor die laufende zu ende ist, verlängert ebenfalls die Ein-/Ausschaltzeit

=> In allen Fällen kann FHEM einen neuen Status setzen.

Gruß,
Thomas

Ralf9 · 30 März 2018, 18:37:34

Ja, das sind zwei Peerings für einen Taster.

ZitatBei "SHORT_JT_ON -> "ON" // verlängern" bin ich mir nicht sicher. Meinem Verständnis nach kann ich On/Off delay Zeiten nur überspringen, aber nicht verlängern. Das ginge nur für On/Off Zeiten.

Das "SHORT_JT_ON ist für on. Beim Verlängern wird auch bei einer absoluten Zeit der on-Timer mit dem neuen Wert überschrieben.

Ich habe bei mir das "LONG_JT_ON -> "ON" gesetzt.
Wenn dann die short_on_time auf 5 Min und die long_on_time auf 60 Min steht,
dann wird das Licht mit einem kurzen Tastendruck für 5 Min eingeschaltet. Mit einem langen Tastendruck kann dann das Licht auf 60 Min verlängert werden.
Ich verwende nur absolute Zeiten.

Schau mal hier, da wird das im Teil 2 mit der minimalen und absoluten Zeit erklärt (ab der 19 Min):
http://www.homematic-inside.de/software/download/item/expertenparameter

Nachtrag:

Zitat-> Toggle wird ignoriert, [korrekt?]

Toggle verwende ich nicht.

Zitat-> neue Absolute Zeiten überschreiben den timer, auch mit Zeit == 0. [korrekt?]

Ja neue Absolute Zeiten überschreiben auch eine minimale Zeit.
Mir fällt nicht ein in welchem Fall überschreiben mit Zeit == 0 Sinn macht.
Hast Du mir für Zeit == 0 ein Beispiel.

ZitatAbsolute Zeit läuft:
alle Änderungen (über peerings) werden ignoriert - bis auf neue absolute Zeit, bis der timer abgelaufen ist [korrekt?]

Mir ist nicht klar wie das gemeint ist.

Gruß Ralf

loetmeister · 30 März 2018, 22:16:15

Hallo,

Zitat von: Ralf9 am 30 März 2018, 18:37:34
Das "SHORT_JT_ON ist für on. Beim Verlängern wird auch bei einer absoluten Zeit der on-Timer mit dem neuen Wert überschrieben.

Ich habe bei mir das "LONG_JT_ON -> "ON" gesetzt.
Wenn dann die short_on_time auf 5 Min und die long_on_time auf 60 Min steht, dann wird das Licht mit einem kurzen Tastendruck für 5 Min eingeschaltet. Mit einem langen Tastendruck kann dann das Licht auf 60 Min verlängert werden. Ich verwende nur absolute Zeiten.

Schau mal hier, da wird das im Teil 2 mit der minimalen und absoluten Zeit erklärt (ab der 19 Min):
http://www.homematic-inside.de/software/download/item/expertenparameter

Ok, danke. Dann habe ich es nun richtig.
Das Video hatte ich mir auch angeschaut und Notizen gemacht, aber es lohnt sich es ein zweites mal, mit anderen Fragen im Kopf, zu sehen... und auch wenn alle paar Sekunden jemand hustet...

Zitat
Ja neue Absolute Zeiten überschreiben auch eine minimale Zeit.
Mir fällt nicht ein in welchem Fall überschreiben mit Zeit == 0 Sinn macht.
Hast Du mir für Zeit == 0 ein Beispiel.

Mit Zeit == 0 meinte ich "not_used".
Angenommen short_on_time ist 5 Min und die long_on_time auf "not_used". Wenn nun die 5 Min laufen, ich dann eine langen Tastendruck sende, erzwinge ich dann ein ausschalten? (long_jt_on steht auf OFF, bzw. über offdelay -> long_jt_offdelay -> off)

Was noch schön wäre, die Zeiten mit dem dynamischen Faktor zu nutzen, wie im Original, aber nicht als 2 byte Wert. Das wären pro peering 4 zusätzliche bytes.
Ich hatte versucht in der XML die Werte anzupassen, ~~leider klappt es nicht~~. Bei 6 bit für den Wert und 2 bit für den Faktor sollte das maximum 63000 (63 * 1000) sein. Also 6 bits gesetzt und der vorletzte Faktor genommen werden.
z.B. EEPROM: 0x44 -> Faktor 60, Wert 4 -> 4*60 = 240 (Dezimal) -> in FHEM Wert : 240
~~Vermutlich hab ich da was falsch gemacht~~

---> value_size="0.8" nicht 0.6

~~Der Fehler sieht auch nicht gut aus~~

Code Auswählen

2018.03.30 22:07:11 1: PERL WARNING: Use of uninitialized value in multiplication (*) at FHEM/lib/HM485/Device.pm line 1139.

NOT_USED -> alle bits gesetzt und maximaler Faktor => 63 * 6000 = 378000

Code Auswählen

<parameter id="SHORT_ON_TIME">
<logical type="float" min="0.0" max="63000.0" default="378000" unit="s">
<special_value id="NOT_USED" value="378000"/>
</logical>
<physical type="integer" size="1.0" interface="eeprom" endian="little">
<address index="+8"/>
</physical>
<conversion type="float_configtime" factors="1,60,1000,6000" value_size="0.8"/>
<conversion type="integer_integer_map">
<value_map device_value="0xc0" parameter_value="0xff" mask="0xc0"/>
</conversion>
</parameter>

Gruß,
Thomas

Ralf9 · 30 März 2018, 23:18:18

ZitatMit Zeit == 0 meinte ich "not_used".
Angenommen short_on_time ist 5 Min und die long_on_time auf "not_used". Wenn nun die 5 Min laufen, ich dann eine langen Tastendruck sende, erzwinge ich dann ein ausschalten? (long_jt_on steht auf OFF, bzw. über offdelay -> long_jt_offdelay -> off)

Ja, wenn das Licht an ist und die 5 Min laufen, dann wird durch "long_jt_on ->OFF" mit einem langen Tastendruck das Licht ausgeschaltet.
Wenn die long_on_time auf "not_used" steht, dann wird mit einem langen Tastendruck das Licht eingeschaltet und bleibt an.
Wenn die long_on_time auf 0 steht, dann dürfte mit einem langen Tastendruck das Licht nicht mehr eingeschaltet werden können.

ZitatWas noch schön wäre, die Zeiten mit dem dynamischen Faktor zu nutzen, wie im Original, aber nicht als 2 byte Wert. Das wären pro peering 4 zusätzliche bytes.

Ich verwende den selben dynamischen Faktor, wie im Original.

Gruß Ralf

Shortie · 01 April 2018, 13:25:50

Ich nutze aktuell Arduino Nano, Max487 und dazu solche Step Down Regler um von den 24V auf 5V zu kommen: https://www.amazon.de/gp/product/B072BMBNG1

Mein Problem ist das mir aktuell reihenweise die Max487 sterben und ich nciht nachvollziehen kann warum. Unter anderem passiert das sogar beim Anstecken an einen leeren Bus (sind trotzdem schon mehrere Meter Kabel), Anschluss am Bus habe ich dabei über solche Stecker realisiert https://www.amazon.de/gp/product/B01MY8FLMV

Die Buchse sitzt dabei auf den HBW Devices mit folgender Belegung 1 - 24V, 2 - A, 3 - B, 4 - GND.

Hat jemand eine Idee woran das liegen kann? Kann man die Eingänge des Max487 auf einfache Art etwas absichern?

loetmeister · 01 April 2018, 14:24:04

Hi,

Mit leeren Bus meinst du einfach die Spannungsversorgung anlegen?
Dann hätte es ja nichts mit den Eingängen zu tun...

Hast du nach dem step down Wandler noch ein Elko oder weitere Kondensatoren?

Driver enable pin ist mit einem pull down verbunden? (und muss vom Arduino auf high gezogen werden)

Gruß,
Thomas

Shortie · 01 April 2018, 14:42:19

Hi,

mit leerem Bus meine ich 24V und Gnd liegen an. Sonst keine weiteren Devices dran.
Der Step Down geht direkt auf den Arduino und Max487, ohne weitere Elkos oder Kondensatoren.
Der Max487 ist wie im Tutorial beschaltet, also RO an D4, RE und DE zusammen an D3 und DI an D2. A und B gehen direkt auf den Bus.

Ralf9 · 01 April 2018, 15:47:30

Bedeutet bei Dir leerer Bus auch, daß die 24V abgeschaltet sind?
Haben das GND vom Max487 und das GND vom Bus evtl verschiedene Potentiale?
Ich verwende den LT1785.

Gruß Ralf

Langerrenner · 01 April 2018, 18:31:05

Hallo Shortie,
beim stecken ist nicht sicher gestellt welcher Kontakt zuerst Kontakt macht. Da Du die 24V außen aufgelegt hast, kann es sein das Du zuerst die 24V und als nächstes den Bus A mit dem System verbindest. Der Max487 sieht nun 24V für kurze Zeit an seinen Eingängen. Das dürfte ihn zerstören.
Abhilfe: Zwei Stecker verwenden für Spannung und Bus. Oder Überspannungsfestere Typen als den MAX verwenden. Für den RS485 Bus gibt es Typen bis 60V Spannungsfestigkeit (Texas).
Oder Schutzbeschaltung. Ist später in der Anlage auch von Vorteil. Zwei 10Ohm in die Leitungen A und B. Zwischen Widerstände und Treiberbaustein Klemmdioden nach 5V und Masse.
So ist auch meine Anlage aufgebaut.
Gruß Willi

Shortie · 01 April 2018, 20:34:02

Hi,

danke für die Ratschläge das erklärt die Probleme die ich aktuell habe.

Ich habe mal geguckt und die LT 1785 gefunden, die bis 60V Spannungsfest sind und auch Pinkompatibel zum Max487 sind. Wobei die Schutzschaltung trotzdem sehr sinnvoll klingt.

Nur ist es dann wohl sinnvoll sich doch wieder um eine kleine Platine Gedanken zu machen.

Gruß