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

[loetmeister]

Hi,

du könntest nur die Serielle Ausgabe in setup() verschieben... z.B.:

Code Auswählen Erweitern

  Serial.print(F("My address: "));
  Serial.println(getBusAddr());
  Serial.print(F("Destination address: "));
  Serial.println(getBusDest());

nach Serial.begin().
Schöner wäre, wenn das in einer "init" Funktion, o.ä. - als Teil der BSB Klasse existiert...

Wozu war eigentlich:

Code Auswählen Erweitern

  while (Serial.available()) {
    DebugOutput.print(Serial.read());
  }
War es um sicher zu stellen, das nicht Zeichen im Puffer als Befehl erkannt werden?

Gruß,
Thomas

[freetz]

Ja, das Verschieben der Ausgabe als solche ginge, aber ich würde auch gerne bei jedem Aufruf der Funktion (z.B. wenn man mit /P wechselt) auch eine Debug-Ausgabe erzeugen, und das ginge damit dann ja nicht, außer ich füge die Ausgabe auch an den anderen Stellen hinzu, was aber unnötig Speicher verbrauchen würde.

Das Einlesen vom seriellen Port hatte ich als eben solche Vorsichtsmaßnahme hinzugefügt, weil manchmal noch wirre Zeichen nach der Initialisierung im Buffer waren. Kann aber sein, dass das unnötig ist.

[Schotty]

Auch von mir ein frohes neues Jahr an alle!

Ich überlege mir mal, ob ich für das Setzen der Raumtemperatur und des Betriebsmodus eine eigene "Kategorie" einführe, damit man diese dann selektiv über die Config dann schreibbar schalten kann, wenn man das nur für diese braucht.

Verständnisfrage:
Wird dann die gesamte 'Kategorie' mit den gesammelten Parametern über die config.h schreibbar gemacht oder kann man dann einzelne Parameter aus dieser Kategorie auswählen und schreibbar machen?
Sprich, wenn bspw 30 Parameter in dieser 'Kategorie' gesammelt sind - kann ich dann auch nur einen oder zwei Parameter davon schreibbar machen oder muss ich mich entscheiden, ob ich alle 30 oder keine Parameter schreibbar machen möchte?

Letzteres würde ich nicht so sinnvoll finden, dann könnte es imho auch beim generellen FL_RONLY/0 bleiben. Wenn ich allerdings aus der Vorauswahl bspw nur einen Parameter auswählen und alle anderen trotzdem nur als lesbar lassen kann, dann würde ich es gut finden und als Bereicherung für BSB-LAN ansehen.

Stellt sich dann allerdings die nächste Frage, nämlich was mit Parametern ist, die dann nicht in der Kategorie mit aufgeführt sind und trotzdem als schreibbar gemacht werden sollen - käme ab dem Zeitpunkt wieder das generelle FL_RONLY/0-Flag ins Spiel oder müsste man/du in dem Fall diese Exoten in der Kategorie nachtragen?

[freetz]

Es wird ein Definement zusätzlich geben, das ich fest den hier gesammelten Parametern zuweisen werde. Für den Rest gilt Default bzw. das bisherige.

[Jewe]

Gutes neues Jahr wünsche ich Euch allen.

Ich verwende das setzten der Raumtemperatur, das umschalten der Betriebsmodus HK1 und HK2, die Komfort Temperaturen HK1 und HK2 möchte ich in der Zukunft auch setzten.

Grüssle Jens


Gesendet von iPhone mit Tapatalk

[Schotty]

@freetz: Wäre es nicht möglich, die gesammelten Parameter dieser Gruppe in der config.h aufzuführen und dann einzeln aktivierbar zu machen? Wenn mit // auskommentiert, dann sind die Werte nicht für ein Setzen freigegeben? (Also ähnlich wie mit den Logging-, Durchschnitts- und IPWE-Parametern.)
Hintergrund: Sollte wirklich mal ungewollter Fremdzugriff durch eine wie-auch-immer-geartete Attacke erfolgen, so kann weniger Schindluder damit getrieben werden. Wenn man bspw nur die Änderung der BA als setzbar erlaubt, dann kann also nur dieser eine Zustand ungewollt beeinflusst werden, nicht aber jedoch bspw der Zustand der H-Eingänge etc. Oder ist das unbegründete Angst meinerseits?

[Maista]

Moin zusammen,

Gutes Neues Jahr an alle.

Währe es denkbar eine eigene Datei zu haben die sich z.B. "BSB_lan_remote.h" nennt?
Hier schreibt man dann seine Parameter rein welche man fernbedienen will.

Die bräuchte man dann nur bei Updates mit in das neue Verzeichnis kopieren.
So bin ich mit dem Datei-Vergleicher am PC gesessen und habe geschaut was sich in der BSB_lan_defs.h alles geändert hat.

Gruss Gerd

[loetmeister]

Ja, das Verschieben der Ausgabe als solche ginge, aber ich würde auch gerne bei jedem Aufruf der Funktion (z.B. wenn man mit /P wechselt) auch eine Debug-Ausgabe erzeugen, und das ginge damit dann ja nicht, außer ich füge die Ausgabe auch an den anderen Stellen hinzu, was aber unnötig Speicher verbrauchen würde.

Das Einlesen vom seriellen Port hatte ich als eben solche Vorsichtsmaßnahme hinzugefügt, weil manchmal noch wirre Zeichen nach der Initialisierung im Buffer waren. Kann aber sein, dass das unnötig ist.

Ok, danke. Ja den selben Code an mehreren Stellen zu verteilen macht definitiv keinen Sinn... setBusType() ist eigentlich gut geeignet.

Ich habe mal in bsb.cpp
https://github.com/fredlcore/bsb_lan/compare/master...loetmeister:master#diff-3949d69f3210e0322e962713a4016f0bL13

und BSB_lan.ino ein wenig aufgeräumt...
https://github.com/fredlcore/bsb_lan/compare/master...loetmeister:master#diff-1118998d47d0c636c492e49a080339afL6771

Du wolltest ja die Lesbarkeit verbessern. Eventuell ist was brauchbares dabei. 


PS: Sollten Pins 18 & 19 zu exclude_GPIO[] in BSB_lan_config.h.default hinzugefügt werden? Ich hab es in meiner mal gemacht...

Gruß,
Thomas

[freetz]

Danke für die "Aufräumarbeiten", schaue ich mir dann gerne beizeiten noch einmal genauer an - im Moment raufe ich mir gerade noch an anderer Stelle die Haare und frage mich gerade, ob ich vor Weihnachten halluziniert habe, als ich das Schaltbild von hier:
https://forum.fhem.de/index.php/topic,29762.msg998591.html#msg998591
aufgebaut hatte und bis gestern Abend felsenfest davon überzeugt war, dass das so auch funktioniert hat.
Als ich es heute weiter testen wollte, leuchtete die Bus-LED nicht mehr. Zuerst dachte ich, dass ein Bauteil nicht mehr richtig im Steckbrett saß, aber am Ende stellte sich heraus, dass an der Basis wohl doch zu viel Strom ankam und der Transistor durchschaltete und die LED deswegen dunkel blieb. Ich hatte da (anders als im Schaltplan) mit 4k7 als Pull-Up aufgebaut. Als ich den gegen 10k austauschte, ging die LED an, aber spürbar dunkler, als bei der V2-Platine. Erst nachdem ich den Aufbau mit dem Mega verbunden hatte, leuchtete die LED so, wie bei der V2-Platine.

Abgesehen davon, dass ich mir beim besten Willen nicht erklären kann, warum es vor Weihnachten mit genau diesem Aufbau lief, verstehe ich nicht, warum a) der Transistor bei 4k7 komplett durchschaltet und bei 10k immerhin noch so viel durchlässt, dass die LED nur schwach glimmt, und b) warum das Verbinden mit dem Arduino dazu führt, dass die LED dann "normal" leuchtet - die Arduino-Seite ist doch von der BSB-Seite galvanisch getrennt, das dürfte doch gar keinen Einfluss haben?

@loetmeister und andere Elektronik-Versierte, habt Ihr eine Idee? Mich nervt ja nichts mehr, als uneindeutige Fehler, die man dann nicht vernünftig troubleshooten kann ...

[Maista]

@freetz
Moin,
hm, also ich tu mich da etwas schwer mit der angegebenen Darstellung weil auf BSB-Seite die Emitter alle oben liegen
Ich bin da eher Emitter bei NPN nach Unten-Zeichnen orientiert

Aber wenn ich die Zeichnung mit meiner aus
https://forum.fhem.de/index.php/topic,29762.msg877496.html#msg877496
vergleiche, meine ich, das Du die Basiswiderstände falsch angeschlossen hast? Kann das sein?
Am OK2 der R1 geht auf "-CL2" was BSB-Seitig GND ist. In der alten Schaltung war das als Art Darlington geschaltet.
Dort geht der Basis-Widerstand auf den Emitter von OK2.
Auf der Arduino-Seite an OK1 wiederum geht der Basis-Widerstand R4 nicht auf GND sondern auf den Emitter von OK1.

Keine Ahnung ob das so gewollt ist.
Hatte nicht verfolgt ob für den Due das anders beschaltet werden sollte.

Wenn Du ausschliessen kannst das in deinem Steckbrett keine Wackler sind kann auch sein das irgend wo ein Takt anlag?

Aber ohne Messung aus der Ferne schwierig.

Gruss Gerd

[loetmeister]

Hallo,

@Gerd, Ziel der neuen Schaltung war es mit USART/Hardware serial ohne invertierung zu arbeiten. Ich fand diese Lösung nicht ganz so glücklich gewählt.

@feetz, das die LED erst nach Anschluss des Arduino korrekt leuchtet, liegt daran das OK2 schalten muss damit der Transistor den Bus nicht kurz schließt.
Warum der 10k pull-up (R5, richtig?) nicht reicht... Gute Frage. Hätte ich nicht erwartet.

Ergänzung: bzgl Transistor. Vermutlich sinkt die Busspannung stark ab, wenn der Transistor beginnt sich zu öffnen. Daher muss der pull-up kleiner sein als man für die Leerlauf Spannung auf dem Bus sonst annimmt.

Gruß,
Thomas

[freetz]

Danke, Ihr beiden, jetzt sehe ich die Dinge etwas klarer - der Transistor schaltet ohne Platine durch, weil der Widerstand R5 mit 4k7 zu klein gewählt ist, bzw. geht die LED bei 10k erst dann vom Glimmen zum Leuchten über, wenn durch die anliegende Spannung auf Arduino-Seite an OK2 der Transistor in OK2 schaltet, richtig?

Was ich noch nicht ganz verstehe: Wenn der Transistor in OK2 schaltet, dann fließt doch aber trotzdem immer noch (der gleiche?) Strom von CL+ über R5 (egal ob nun 4k7 oder 10k?) zur Basis des Transistors auf Bus-Seite und er müsste doch dann in jedem Fall weiter so schalten, wie wenn keine Spannung an OK2 anliegen würde, oder was übersehe ich da?

Ich sehe nun den Vorteil von Deiner Schaltung, Thomas, die aber wie gesagt wegen des noch zu berücksichtigenden I2C-EEPROMs aus Platzgründen beim besten Willen (ohne auf eine 4-lagige Platine zu wechseln) nicht umzusetzen war. Macht es dann Sinn den Pull-Up auf BSB-Seite noch (deutlich) zu erhöhen, oder kann man sagen, dass es reicht, wenn es mit 10k "glimmt", wenn nichts weiter an die Schaltung angeschlossen ist? Oder sollte man dann gleich auf 100k gehen?

Danke Euch und VG, F.

[Jewe]

Guten Morgen,

vor ein paar Tagen habe ich festgestellt, dass meine Heizung trotz eingestelltem Tagesprogramm mit Nachtabsenkung die ganze Nacht durchheizt. Die eingestellten Zeiten scheinen die Heizung nicht zu interessieren.
Hat jemand einen Ahnung warum das so ist ?
Der eine Heizkreis ist auf 0% und der 2. auf 70% Raumeinfluss eingestellt. Der Kreis mit 0% hängt am selben RGT wie der andere.



Gesendet von iPhone mit Tapatalk

[freetz]

@Jewe: Pumpendauerlauf wegen Frostschutz o.ä.? Ist vermutlich eine Einstellungssache, kann meiner Meinung nach nichts mit BSB zu tun haben.

@loetmeister und @Maista: Und noch eine Verständnisfrage, was den Stromfluss angeht (auf meinen Schaltplan bezogen):
Von CL+ kommend teilt sich der Strom ja auf die Widerstände R2 und R5 auf. Bei einem Verhältnis von 10k zu 1k5 würden also nur ca. 16% hinter R5 ankommen und diese würden sich dann noch mal im Verhältnis 1:1 zwischen dem Transistoreingang von OK2 (nur wenn er selber durchschaltet?) und der Basis des (leider in dem Schaltplan nicht benannten) Transistors ankommen, was dann im Endeffekt ca. 8% wären.

Wenn man nun die 10k gegen 4k7 austauscht, wäre man bei ca. 32% hinter R5 und demzufolge bei je 16% an OK2 und der Basis des Transistors.

Soweit korrekt?

Das heißt, dass aber immer ein gewisser Strom an der Basis des Transistors ankommt, und dieser immer in einem gewissen Maße durchschaltet und damit auf das Bussignal einwirkt, oder? Woher weiß man dann, wann es so "zu viel" ist, also dass er auch dann noch durchschaltet, wenn er es eigentlich nicht mehr soll, weil OK2 durchschaltet? Kann man das irgendwie berechnen oder muss man das durch Ausprobieren herausfinden?

[Jewe]

Ja klar, das ist ein wenig OT und hat nichts mit BSB zu tun. Sorry.


Gesendet von iPhone mit Tapatalk