LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

Luposoft · 15 Dezember 2019, 01:58:44

@freetz
ich habe mir mal die Zeit genommen, und an der Therme mal vorerst die Parameter "Kessel" am SerMon verglichen.
Entstanden ist die angehängte Datei.
Könntest du dir das bitte angucken ob das so ausreicht und ins Git laden? Danke schon mal jetzt.
Für die weiteren Vergleiche... ist die Darstellung in der Datei für dich so überhaupt gut?

Eine Frage hätte ich noch, ich würde gerne am BSB-Lan-Arduino eine Photodiode am analogen Port betreiben wollen. Ich würde gerne Beleuchtung anhand der Helligkeit einschalten können.
Ist eine Implementierung in die bsb-lan-Software überhaupt denkbar?

Schotty · 15 Dezember 2019, 09:37:34

Zitat von: Luposoft am 15 Dezember 2019, 01:58:44
Eine Frage hätte ich noch, ich würde gerne am BSB-Lan-Arduino eine Photodiode am analogen Port betreiben wollen. Ich würde gerne Beleuchtung anhand der Helligkeit einschalten können.
Ist eine Implementierung in die bsb-lan-Software überhaupt denkbar?

Du kannst schon jetzt (zumindest ja mal probeweise) mit dem File "BSB_lan_custom.h.default" eigenen Code einbinden, musst nur sehen, obs dann vom Speicher her noch passt. Das ".default" dann beim Filenamen entfernen.

freetz · 15 Dezember 2019, 13:44:15

@luposoft: Genau wie Schotty sagt, ist die BSB_lan_custom.h für solche Dinge gedacht. Sie wird am Ende eines jeden loop()-Durchlaufs aufgerufen und damit kann man dann z.B: Sensoren abfragen und bestimmte Aktionen ausführen (z.B. Parameter über set() setzen etc.).

Was Deine Parameter angeht, ist die Zusammenfassung 1a mit Sternchen

. Nur die Gerätevariante musste ich noch nachschlagen, weil es "DEV_195" bei 2444 nicht gibt und ich den Text mit "Variante 2" nicht sofort auf Deine Gerätevariante bezogen hatte. Abweichungen von der Gerätefamilie müssten dann in dem Fall mit DEV_195_002 angelegt werden und dann oben in der DEV_-Auflistung entsprechend definiert werden.

Ein paar kurze Rückfragen hätte ich noch:
- Bei Parameter 2238 bist Du (vermutlich korrekterweise) vom Datentyp VT_SECONDS_SHORT ausgegangen. Es gibt der Erfahrung nach aber verschiedene 1-Byte-Sekundenwerte, teilweise wird z.B. der Wert dann durch vier oder fünf geteilt. Bei einem Wert "0" kann man das leider nicht erkennen. Könntest Du den Wert ganz kurzzeitig mal auf einen Wert grüßer 0 stellen und dann noch mal das Telegramm abgreifen, damit wir da auf der sicheren Seite sind?

- 2444 ist bei Dir "Gebläsedrehzahl TWW Max.", allerdings hast Du es bei STR2444_2 belassen, was "Gebläseleistung TWW Max." ist. Wenn der Text bei Dir stimmt, würde ich STR2444_3 neu hinzufügen. Das Gleiche gilt für 2452.

- Du hattest auf GitHub auch noch eine Reihe von Parametern vorgeschlagen, die hier aber nicht mit drin sind, kannst Du die auch noch so aufbereiten?

Danke auf jeden Fall noch mal für's Loggen und Dekodieren - neue Parameter sind ja heutzutage eher selten geworden (was ja ansonsten für den schon bestehenden Umfang spricht)...

Die neueste Version (mit meinen o.g. Annahmen) ist auf GitHub, vielleicht kannst Du's auch damit gleich mal testen...

Luposoft · 15 Dezember 2019, 16:17:39

@freetz
Du bist aber schnell! Respekt
Ich kann mich morgen mit deinen Fragen befassen. Ich melde mich

Zu meinem Projekt...Helligkeitsmessung
Wie ich die Werte auf meinen Arduino bekomme ist klar, so denke ich zumindest
(In der lan_custom.h.default ist ja ein schönes Beispiel)
Ich brauch die Werte aber auch übers Web, damit FHEM was machen kann.
Da ich am offenen Herzen operieren muss, mein Arduino hat ja zu tun,
will ich try and error auf ein Mindestmaß beschränken.

Daher noch eine Frage. So wie ich das grad sehe, muß ich ja auch was in der BSB_lan_defs.h und Lang_de.h definieren.
Oder gibt es dafür auch eine Möglichkeit in den custom-Files?

freetz · 15 Dezember 2019, 19:26:44

Stimmt, an die Web-Ausgabe hatte ich bisher noch nicht gedacht, habe das jetzt mal schnell nachgetragen, es gibt jetzt zwei globale Arrays, die jeweils 20 Byte groß sind, custom_floats[] und custom_longs[]. Auf diese kann man in der _custom.h zugreifen und Variablen in diese schreiben. Über das neue URL-Kommando /U werden diese stumpf nacheinander ausgegeben.

An den Sprachdateien musst Du bei der _custom.h gar nichts ändern, denn außer die hat die ja niemand so wie Du. Du kannst also ganz einfach in Deutsch, Englisch oder Malaiisch Deine (dann aber nur auf der seriellen Konsole wirksamen) Ausgaben texten.

loetmeister · 15 Dezember 2019, 21:50:20

Hi,

nachdem der Adapter läuft - Danke an alle die zu diesem Projekt beigetragen haben

- poste ich hier meinen Schaltplan. Ist, wie erwähnt nur leicht abgewandelt. Ausgelegt für 5V mit Arduino und USART/HardwareSerial.
Bei RX habe ich mir den zweiten Transistor eingespart. Dafür eine Diode gegen versehentliches Verpolen eingebaut... (würde den TX Optokoppler und Transistor schützen).

EDIT: Im Schaltplan Wert für R6 ergänzt.

Gruß,
Thomas

freetz · 15 Dezember 2019, 22:33:39

Prima, danke!
Da ich mich ja erst durch dieses Projekt tiefer mit solchen elektronischen Schaltungen beschäftige, würden mich ein paar Dinge interessieren, vielleicht kannst Du mir da ja die Hintergründe etwas erklären?

- Warum invertierst Du beim TX-Pfad (also OC2) über einen PNP-Transistor im Vergleich zu der Invertierung am Ausgang von OC2 über einen 10k Widerstand wie in meinem Entwurf? Im Vergleich spart Deine Lösung einen Widerstand und hat dafür einen Transistor mehr. Ist dafür dann das Signal sauberer/stabiler?

- Warum macht es mehr Sinn, beim RX-Pfad (OC1) bei der Invertierung mittels Widerstand am Ausgang von OC1 zu bleiben, anstatt dort auch über einen Transistor zu invertieren?

- Ich musste bei meiner Variante auch im RX-Pfad (OC1) einen 560k-Widerstand zwischen die Pins 4 und 6 setzen, damit die Daten stabil am Arduino ankamen, andernfalls hatte ich immer wieder Aussetzer bzw. unvollständige Bytes. Kannst Du Dir erklären, warum der bei Dir nicht nötig ist (bzw. auch bei dem ursprünglichen Schaltplan anscheinend nicht nötig war)?

- Warum ist D3 zusätzlich zu D1 nötig, die bisher ja auch für einen Verpolungsschutz gesorgt hat? Bzw. braucht man dann D1 noch, bzw. könnte man D1 nicht einfach an die Stelle von D3 setzen? Die beiden Dioden direkt hintereinander erscheinen mir irgendwie doppelt gemoppelt?

- Gibt es einen Grund, warum Du R4 bei 3,3V auf 4,7kOhm reduzieren würdest, aber R6 nicht? Oder ist der Wert in Klammern einfach nur weggelassen?

Falls Du mir dazu Deine Einschätzungen schreiben könntest, würde mich das sehr freuen, weil ich solche Schaltungen zwar oft so hinbekomme, dass sie laufen, aber meistens nicht sagen kann, ob das auch der beste Weg ist, um so etwas umzusetzen

...

Danke und VG, F.

loetmeister · 16 Dezember 2019, 00:23:05

Hi,

ich versuche das mal zu beantworten.... nach meinem besten Wissen.

Zitat von: freetz am 15 Dezember 2019, 22:33:39
- Warum invertierst Du beim TX-Pfad (also OC2) über einen PNP-Transistor im Vergleich zu der Invertierung am Ausgang von OC2 über einen 10k Widerstand wie in meinem Entwurf? Im Vergleich spart Deine Lösung einen Widerstand und hat dafür einen Transistor mehr. Ist dafür dann das Signal sauberer/stabiler?

Bei deinem Entwurf (https://forum.fhem.de/index.php/topic,29762.msg998591.html#msg998591 - für alle die Mitlesen

) würde die LED in OK2/OC2 immer geschaltet sein. Daher habe ich die Invertierung, wie im Original auf der Arduino Seite belassen.

Zitat- Warum macht es mehr Sinn, beim RX-Pfad (OC1) bei der Invertierung mittels Widerstand am Ausgang von OC1 zu bleiben, anstatt dort auch über einen Transistor zu invertieren?

- Ich musste bei meiner Variante auch im RX-Pfad (OC1) einen 560k-Widerstand zwischen die Pins 4 und 6 setzen, damit die Daten stabil am Arduino ankamen, andernfalls hatte ich immer wieder Aussetzer bzw. unvollständige Bytes. Kannst Du Dir erklären, warum der bei Dir nicht nötig ist (bzw. auch bei dem ursprünglichen Schaltplan anscheinend nicht nötig war)?

Auf RX Seite habe ich ja schon einen Transistor im Optokoppler. Wenn der sauber schaltet brauche ich eigentlich keinen zweiten...
Den 560k hatte ich auch mal zum testen drin, hatte aber keinen erkennbaren unterschied gemacht. Eventuell schau ich mal mit dem Scope ob die Signalflanken mit Widerstand besser sind... (falls das überhaut zu erkennen ist)
Der unterschied könnten 1,7V sein... ich hab 5V anliegen - du hattest mit 3,3V getestet? Eventuell bist du da an der grenze was als HIGH oder LOW Pegel erkannt wird... Hast du mal ohne 560k, aber mit 4,7k bei R6 probiert? Eventuell ist 10k bei 3,3V als pulldown zu schwach..

Zitat- Warum ist D3 zusätzlich zu D1 nötig, die bisher ja auch für einen Verpolungsschutz gesorgt hat? Bzw. braucht man dann D1 noch, bzw. könnte man D1 nicht einfach an die Stelle von D3 setzen? Die beiden Dioden direkt hintereinander erscheinen mir irgendwie doppelt gemoppelt?

Nötig ist D3 nicht... D1 schützt die LED und OK1. D3 habe hauptsächlich ich für den TX Transistor/OK spendiert. Eventuell ist der OK bereits aussprechend Spannungsfest gegen die Sperrichtung (Verpolung). Wenn man D3 einsetzt, ist D1 eigentlich Überflüssig. Es fallen da aber ca. 0,5V ab. Wenn das weg fällt dann müsste ich R2 (1k5) streng genommen erhöhen um den selben Strom für die Dioden (LED & OK) bei zu behalten.

Zitat- Gibt es einen Grund, warum Du R4 bei 3,3V auf 4,7kOhm reduzieren würdest, aber R6 nicht? Oder ist der Wert in Klammern einfach nur weggelassen?

Hatte ich vergessen....

könnte tatsächlich knapp sein, um bei 3,3V den Transistor sicher zu schalten. Mit 4,7k bist du da auf der sicheren Seite.

Gruß,
Thomas

freetz · 16 Dezember 2019, 09:29:43

Dank' Dir sehr, das macht die Dinge doch noch mal um einiges klarer für mich. Nur noch drei Nachfragen:

Zum einen zu dem Transistor bei OC2/OK2: Das mit der dauerbeschalteten LED stimmt natürlich, und ich hatte vergessen, dass durch die Invertierung in SoftwareSerial die auch im ursprünglichen Design ja nicht dauerhaft brennt. Auf der anderen Seite brennt die LED in OC1/OK1 ja auch dauerhaft, wäre es dann nicht sinnvoll, diesen Weg auch auf bei OC1/OK1 zu gehen?

Zum anderen zum angepassten Vorwiderstand, falls man D1 weglässt und nur D3 verwendet: Müsste dann nicht in Deinem jetzigen Schaltplan mit drei Diosden der Vorwiderstand niedriger als die bisherigen 1,5kOhm sein? Denn bei mehreren LEDs in Reihe sinkt dieser doch? Und reicht es nicht, sich bei der Berechnung des Vorwiderstands auf die LED im Optokoppler zu konzentrieren? Denn ob die nachgeschaltete LED etwas heller oder dunkler leuchtet, ist ja nicht so wichtig, oder? Überhaupt scheinen mir die 1,5kOhm immer noch großzügig dimensioniert zu sein, denn wenn man von 10mA Nennstrom und 1,1V Spannungsabfall im Optokoppler ausgeht, käme ich auf einen Vorwiderstand von 1440 Ohm - und da ist der Spannungsabfall an der LED und der 1N4848 noch nicht berücksichtigt. Darüber hinaus nennt das Datenblatt des 4N25 eine Continuous Forward Current von 60mA, was den Vorwiderstand noch geringer machen würde, oder?

Hat es darüber hinaus einen Grund, dass Du eine Schottky-Diode anstatt der 1N4148 genommen hast? Letztere hält doch Spannungen bis 100V aus, kann man die dann nicht einfach an die Stelle von D3 setzen?

Was den 560k am Ausgang von OC1/OK1 angeht, so habe ich bisher alle Tests noch mit den 5V vom Arduino gemacht. Ich habe mich insofern gewundert, dass es da Probleme gab, weil das geplante Design in dem Fall kaum vom ursprünglichen abweicht. Vielleicht habe ich aber auch nur einen sensiblen Optokoppler erwischt, aber auch das würde mich wundern, denn das wäre bei allen Platinen das erste Mal, dass dieses Problem aufgetaucht ist.

Dank' Dir und VG, F.

miwi · 16 Dezember 2019, 14:17:06

Ich bin mal wieder am computern und habe den Computer auf die Datei BSB_lan_defs.h losgelassen. Neben Dubletten bei den cmdCodes, die Du ja selbst auch regelmaessig findest (zumindest war das frueher so), habe ich zwei andere Anmerkungen.

Bemerkung: Der Computer setzt die BSB_lan_defs.h Definitionen in eine formale XML-Darstellung um. Daraus kann ein spaeterer Programmcode die Information ziehen, wie er ein Kommando verarbeiten muss. Vielleicht erinnern sich manche an weit zurueckliegende Beitraege. Der Code dafuer existiert bei einem OpenHAB add-on.

Erstens: Es gibt eine Anzahl Kommandos vom Typ VT_ENUM, der eine Querverweisliste (map) mit 8-bit Integer : String Verweisen definiert. Die Zahlenwerte bei dieser Anzahl Kommandos sind z.T. groesser als 255, passen also nicht in ein 8-bit VT_ENUM. Hier sind die ProgNo
[ERROR] progNo=08006 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08006)
[ERROR] progNo=08051 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08051)
[ERROR] progNo=08053 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08053)
[ERROR] progNo=08055 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08055)
[ERROR] progNo=08057 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08057)
[ERROR] progNo=08059 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08059)
[ERROR] progNo=08061 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08061)
[ERROR] progNo=08063 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08063)
[ERROR] progNo=08065 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08065)
[ERROR] progNo=08067 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08067)
[ERROR] progNo=08069 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08069)
[ERROR] progNo=08099 Cannot present 256 in an 8-bit VT_ENUM type.
(weitere Meldungen zu progNo=08099)
[ERROR] progNo=08304 Cannot present 256 in an 8-bit VT_ENUM type.

Fuer diese Querverweislisten muesste korrekterweise eine map mit 16-bit integer : Textstring verwendet werden. Es haette sich der Int16-Typ VT_ERRORCODE angeboten, aber der existiert nicht nur bei Querverweislisten. Das fuehrt zu

Zweitens: Der Typ VT_ERRORCODE existiert in zwei Verwendungen:
// ATTENTION: There are several commands of type VT_ERRORCODE. Some
// come with a selection list of 16-bit error codes, others do not
// have such a selection list. The former ones must finish the
// XML entry with a ">", followed by the selection list definition.
// The latter w/o a selection list must end the XML definition
// with a "/>"
// List of progNo which have an error code list:
String[] withList = { "6705", "6835", "6845", "6855", "6865", "6875",
"6895" };
// List of progNo cmds of type VT_ERRORCODE which have no error code list.
String[] noList = { "6801", "6803", "6805", "6807", "6809", "6811", "6813",
"6815", "6817", "6819", "6901", "6911", "6921", "6931", "6941",
"6951", "6961", "6971", "6981", "6991" };

Das kann (muss) ich natuerlich im Code beruecksichtigen, der den XML-Ouput generiert. Es sind halt so kleine quirks im Ausgangstext, "which throw a curve ball to the computer". In der noList Gruppe sind jeweils Kommandos, die auf eine bestimmte Meldung verweisen. Wozu dient eigentlich der 16-bit Wert bei den Kommandos aus der noList, Gruppe? Faellt der nicht einfach unter den Tisch? Dann waere ein Typ Int16, dessen Wert evtl. nicht ausgewertet wird, auch denkbar.

Ach ja, ProgNo 8025 ist als Typ VT_ENUM definiert. Eine ENUM8025 selection list habe ich aber nicht gefunden.

Bratmaxe · 16 Dezember 2019, 16:20:16

Hallo zusammen,
ich versuche mich gerade mal an der Arduino 2560 mit integriertem ESP8266 WLAN Modul.
Ich konnte sowohl den ESP als auch den Arduino flashen, leider baut der ESP keine WLAN Verbindung auf.
Im Monitor kommt die Meldung: [WiFiEsp] >>> TIMEOUT >>>
Geflasht habe ich mit der ESP8266Flasche.exe. Testen wollte ich mit dem HTerm-Tool, erhalte aber keine Antwort wenn ich "ATI" als ASC sende.

Habt ihr Vorschläge, wie ich hier weiter vorgehen könnte? Oder Tipps, wo mein Fehler liegen könnte?

Gruß Bratmaxe

loetmeister · 16 Dezember 2019, 19:33:49

Zitat von: freetz am 16 Dezember 2019, 09:29:43
Auf der anderen Seite brennt die LED in OC1/OK1 ja auch dauerhaft, wäre es dann nicht sinnvoll, diesen Weg auch auf bei OC1/OK1 zu gehen?

Ja, wäre gut.. aber: Der Bus ist 'High' oder 'Low' - in letztem Fall liegt ja keine Spannung mehr an. Wie kann ich da (ohne Hilfsspannung) einen Transistor oder LED schalten?

Bus-Leerlaufspannung 15,5 V ± 10 % (unbelastet)
Signalpegel < 7 V: logisch '1', > 9 V: logisch '0'
https://www.mikrocontroller.net/topic/218643

EDIT: Hab mal den mikrocontroller.net Beitrag nach Schaltplänen durchgeschaut.... gibt eine Variante mit DC-DC Wandler... da ist aber der Aufwand deutlich höher, und ob der Wirkungsgrad des Wandlers die dauer leuchtende LED ausgleicht... eher nicht.
https://www.mikrocontroller.net/attachment/286392/LPBInterfaceSchematic.png
Hatte auch bzgl TX Transistor geschaut... es gab ein paar Versionen mit 100Ohm Widerstand zur Begrenzung des Kollektor - Emitter Stroms, aber die meisten knallen CL+ auf CL-...

ZitatZum anderen zum angepassten Vorwiderstand, falls man D1 weglässt und nur D3 verwendet: Müsste dann nicht in Deinem jetzigen Schaltplan mit drei Diosden der Vorwiderstand niedriger als die bisherigen 1,5kOhm sein? Denn bei mehreren LEDs in Reihe sinkt dieser doch? Und reicht es nicht, sich bei der Berechnung des Vorwiderstands auf die LED im Optokoppler zu konzentrieren? Denn ob die nachgeschaltete LED etwas heller oder dunkler leuchtet, ist ja nicht so wichtig, oder? Überhaupt scheinen mir die 1,5kOhm immer noch großzügig dimensioniert zu sein, denn wenn man von 10mA Nennstrom und 1,1V Spannungsabfall im Optokoppler ausgeht, käme ich auf einen Vorwiderstand von 1440 Ohm - und da ist der Spannungsabfall an der LED und der 1N4848 noch nicht berücksichtigt. Darüber hinaus nennt das Datenblatt des 4N25 eine Continuous Forward Current von 60mA, was den Vorwiderstand noch geringer machen würde, oder?

Hat es darüber hinaus einen Grund, dass Du eine Schottky-Diode anstatt der 1N4148 genommen hast? Letztere hält doch Spannungen bis 100V aus, kann man die dann nicht einfach an die Stelle von D3 setzen?

Ja, du könntest auch 1N4148 nhemen... ich wollte aber nicht zu viel ändern. Die Schottky Diode hatte ich genommen, da sie einen sehr geringen Spannungsabfall erzeugt, ca. 0,2V. Damit vernachlässigbar... aber deine Überlegungen sind vollkommen richtig.. die Summe machts.
Wobei der Bus scheint da sehr große Toleranzen erlaubt. Gehe ich von 15V aus, die ich gemessen hab - dann habe ich Spannungsabfälle in den Bauteilen: LED rot ca. 1,6V, 1N4148 0,6V, OK 1,1V (+meine extra Diode 0,2V) = 3,5V --> 7,6mA bei 1,5kOhm (gilt für alle Bauteile, OK, LED, etc. da Reihenschaltung)
Ich hatte 3 Meter Kabel zwischen Bus und Adapter (0,75mm²). Ich messe mal die Tage Spannung, Strom und Kurzschluss Strom....

Was ich auch spannend finde, das der TX Transistor den Bus kurz Schließt - also auf die Strombegrenzung des Bus vertraut...

"4N25 Continuous Forward Current von 60mA" - das würde ich vermeiden. Das ist das absolute Maximum. Ab ca. 10mA steigt das Übertragungsverhältnis nicht weiter an... mehr als 20mA würde ich nicht machen. Zumal dir dann auch irgendwann die LED abraucht...

ZitatWas den 560k am Ausgang von OC1/OK1 angeht, so habe ich bisher alle Tests noch mit den 5V vom Arduino gemacht. Ich habe mich insofern gewundert, dass es da Probleme gab, weil das geplante Design in dem Fall kaum vom ursprünglichen abweicht. ...

Ok, das ist komisch. Ich hab nur mit einem Logiktester den RX Pegel geprüft - der war ok... nicht die Spannung gemessen. Eventuell sind die Pins des Ardunio Mega clons und des Originals etwas anders beschaltet?

Gruß,
Thomas

freetz · 16 Dezember 2019, 23:23:46

Danke für die Rückmeldung - und stimmt natürlich mit der fehlenden Spannung, grrrr

... Die Schaltung auf mikrocontroller.net (und andere) kenne ich auch, aber die jahrelangen problemlosen Erfahrungen mit dieser Variante würden mich (auch wengen des Formfaktors für Arduino-Standardgehäuse) nicht auf eine noch aufwändigere Schaltung wechseln lassen wollen.
Danke auch für's Angebot des Nachmessens der Ströme etc., das wäre noch mal eine ganz hilfreiche Info.

Der Kurzschluss auf dem Bus als logische 1 hat mich auch damals sehr überrascht, zumal es gleichzeitig auch trotzdem eine Fehlermeldung "Kurzschluss BSB" (oder so ähnlich) geben kann (vermutlich, wenn man länger kurzschließt als nur ein paar Millisekunden?). Wie das dann unterschieden wird, ist mir ein Rätsel...

Das mit der Continuous Forward Current ist auch noch mal ein guter Hinweis, ich hatte im Datenblatt noch was von einer Peak Current von 3A gelesen und wusste dann nicht, was der empfohlene Strom ist, aber das ist dann wohl eher der als "typisch" angegebene Strom von 10mA?

Und was den 560kOhm Widerstand am Ausgang von OK1 angeht, so habe ich da mit dem Logic-Analyzer auch auf den ersten Blick normale Werte bekommen, aber beim genaueren Hinsehen auf die Telegramme erkennt man dann, dass hier und da Bits falsch sind. Und schon durch die falschen Checksummen kann das dann ja zu ganzen Bytes bzw. Telegrammen führen, die nicht erkannt werden. Mit dem eingesetzten Widerstand war das dann kein Problem. War allerdings auch ein Aufbau auf Breadboard, nicht verlötet, vielleicht ist das dann auch noch mal anfälliger? An der Pinbeschaltung kann es nicht liegen, denn dann dürfte ja gar nichts gehen, oder?

miwi · 17 Dezember 2019, 10:49:36

Zitat von: loetmeister am 16 Dezember 2019, 19:33:49
EDIT: Hab mal den mikrocontroller.net Beitrag nach Schaltplänen durchgeschaut.... gibt eine Variante mit DC-DC Wandler... da ist aber der Aufwand deutlich höher, und ob der Wirkungsgrad des Wandlers die dauer leuchtende LED ausgleicht... eher nicht.
https://www.mikrocontroller.net/attachment/286392/LPBInterfaceSchematic.png

Ich kann bestaetigen, dass mehrere Platinen mit dieser Schaltung seit langer Zeit problemlos funktionieren. Nebenbei, im SIEMENS Service Tool ist auch diese galvanische Trennung implementiert.

Gibt es eine Auswahllliste fuer das Kommand mit ProgNo 8025 "Status Kühlkreis 2"? Wenn ja, wo finde ich die?

freetz · 17 Dezember 2019, 12:00:00

@bratmaxe: Sorry, ich habe keinen Windows-Rechner und weiß von daher nur das, was im Handbuch steht. Wenn Du es 1:1 gemacht hast, wie es da beschrieben ist, sollte es funktionieren.

@miwi: Nein, gibt es nicht. Wenn Du die passenden Zuordnungen hast, baue ich sie gerne ein. Zu Deiner anderen Frage: Bei welchem OpenHAB-Modul läuft Dein Programm? Zu OpenHAB kenne ich bisher nur das Modul, das auf unseren JSON-Export setzt.