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

Begonnen von justme1968, 29 November 2014, 19:50:40

Vorheriges Thema - Nächstes Thema

Luposoft

@freetz
Sehr schön, die Änderungen funktionieren soweit.
Mit dem 2238 war deine Vermutung richtig. ist /4
2457 muß dir durch die Lappen gegangen sein
2662/63 bitte noch den Typ ändern.

Du schreibst, ich hätte auf Github Parameter vorgeschlagen...
Ich weiß nicht, was das war, und wo ich da jetzt nachgucken könnte.
Kannst du mir da auf die Sprünge helfen?.
Raspi B+
CUL nano 433MHz
CUL nano 868MHz
ELCO Thision S Plus 19
Arduino Due

freetz

Prima, danke, pflege ich dann heute Abend so ein.
Hier der Link zu dem GitHub Issue, das Du geöffnet hattest:
https://github.com/fredlcore/bsb_lan/issues/39
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

miwi

#4112
Danke wegen 8025.  Nein, mit den Angaben dazu kann ich nicht dienen.  Gefunden hat es mein Programm, das fuer ein Kommando mit Typ VT_ENUM nach der Liste sucht und sie in diesem Fall nicht findet.  (Es ist meistens gut, nach einem if .. auch ein else .. vorzusehen.)  Das Programm gibt jetzt stattdessen aus

        <cmddef  progNo="08025" cmdCode="053D17D1" name="Status Kühlkreis 2" usrlevel="Unknown" payloadType="Int08" length="2" default="Unknown" writeable="false" nullable="false">
            <selections name="sel08025">
            <!-- ERROR - No selection list found for ProgNo 08025 - ERROR -->
            </selections>
        </cmddef>


Statt literaler ASCII strings kann mein Programm aalternativ die von Dir fuer Fremdsprachen eingefuehrten string-Referenzen ausgeben. Das sieht dann so aus:
        <cmddef  progNo="08025" cmdCode="053D17D1" name="STR8025_TEXT" usrlevel="Unknown" payloadType="Int08" length="2" default="Unknown" writeable="false" nullable="false">
            <selections name="sel08025">
            <!-- ERROR - No selection list found for ProgNo 08025 - ERROR -->
            </selections>
        </cmddef>


Dass da Int08 statt VT_ENUM steht, sollte in die Richtung deuten, dass ich nur einige wenige Oberklassen geplant hatte, die die Basis fuer Telegramme mit payloads von entsprechender Laenge bilden.  In Int08 faellt dann auch VT_ENUM.  Der Ansatz ist, alle 8-bit, 16-bit, 32-bit, 9-bit und variable payload Laengen in nur je einer Oberklasse abzuhandeln.  Mal sehen.

Deine Gegenfrage wegen OpenHAB: Ich hatte noch mit OH V1 eine Java-Implementierung der Broetje-Steuerung als OH V1 add-on angefangen, sie aber nicht komplett fertiggestellt.  Es gab damals nicht viele add-ons, die fuer eine Bus-Kommunikation entworfen worden waren; verwendet habe ich dann einen Ansatz, wie er in der Stiebel-Eltron Waermepumpenanbindung schon existierte.  Dieses add-on holt sich die Beschreibung der Kommandos aus einer XML-Beschreibungsdatei, was ich bei meinem OpenHAB Broetje-Projekt entsprechend angepasst uebernommen  habe.  Die Datei hatte ich damals auch mit einem Programm aus den Arduino-Definitionen erzeugt.  (Es sollte fuer mich ja nur einen Goldstandard=Arduino geben).  Die Bruecke manuell schlagen und Aenderungen nachziehen will ich nicht. Die Implementierung meines add-ons funktionierte in meinen unit tests sehr schoen, wenn ich beliebige Kommandos generiert habe.

Inzwischen sind zwei Aenderung passiert: Erstens gibt es eine OpenHAB V2 implementierung des damaligen Stiebel add-ons, zweitens ist  beim Arduino Projekt einiges anders.  Zuerst einmal habe ich mein Programm, das aus den Arduino-Dateien die XML-Beschreibung anfertigt, neu aufgesetzt, ohne die OH V2 Implementierung zu kennen. .  Dabei entstanden dann so manche Erkenntnisse und Fragen, wie man Dinge noch konsistenter :-) machen kann.  Das war eine Fingeruebeung, trotzdem muss ich noch zweitens verifizieren, dass die OH V2 Implementierung noch immer auf einer XML-Beschreibung fusst.  Eine erste Inspektion des Codes stimmt mich optimistisch, dass dies der Fall ist und ichdeshalb  diesen Teil meiner Broetje-Implementierung fuer OH .weiter verwenden kann.  Ich bin aber nur gelegentlich an dem Projekt taetig.

Was ich heute noch gemacht habe:
Dort, wo in der cmdtbl ein VT_ERRORCODE Typ verwendet wird, aber keine Liste existiert, habe ich den Typ auf VT_UINTgesetzt. Beispiel:

{0x053D30B2,  CAT_FEHLER,           VT_UINT,          6961,  STR6961,  0,                    NULL,        .....

Da, wo VT_ENUM mit einer Liste stand, die aber auch Werte GT 255 enthaelt, habe ich den Typ auf VT_ERRORCODE gesetzt.  Beispiel:

CAT_STATUS,           VT_ERRORCODE,     8051,  STR8051,  sizeof(ENUM8051),     ENUM8051,  .....

Die Verwendung des Typs auch an diesen Stellen, auch dann, wenn wir nicht von ERRORCODES sprechen, schien mir weniger aufwaendig als (evtl. zusaetzlich zum VT_ERRORCODE) zwei neue Typen VT_08ENUM und VT_16ENUM einzufuehren und das im Code durchzuziehen. 
Das sieht zwar ein bisschen "kludgy" aus mit VT_ERRORCODE als Typ und ENUMnnnn als Name.  To consolidate this is left as an execise for the gentle reader.  Mein Programm schaetzt einen Input, aus dem es die richtigen Schluesse ziehen kann, und das funktioniert mit den beiden kleinen Anpassungen in BSB_lan_defs.h

Bratmaxe

Moin,

ich bin ein wenig weiter gekommen.

jetzt steht im seriellen Monitor:
[WiFiEsp] Warning: Unsupported firmware 3.0.0
[WiFiEsp] IP address set 192.168.2.100
Attempting to connect to WPA SSID: <MEINWLANNAME>
[WiFiEsp] Failed connecting to <MEINWLANNAME>

Name und Passwort sind definitiv richtig.
Kann das was mit der Meldung Unsupported firmware 3.0.0 zu tun haben?
Welche Firmware meint der und wie kann ich das umgehen?

Gruß Carsten

freetz

Also ich unterstütze ja gerne bei der Fehlersuche, aber wenn der erste Link, den ich finde, wenn ich bei Google "WiFiEsp unsupported firmware" eingebe, genau das Thema behandelt und Lösungsvorschläge gibt, dann finde ich das schon einen etwas sehr selbstverständlichen Umgang mit der Zeit anderer...

https://github.com/bportaluri/WiFiEsp/issues/48
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

Bratmaxe

Danke für den Link, diesen kenne ich, aber leider komme ich damit nicht weiter. Ich habe ja die AT-Firmware 1.7.0 verwendet, wie im Handbuch beschrieben. Laut deren Changelog basiert diese auf "ESP8266_NonOS_SDK V3.0.0" , was die Meldung erklären würde! Laut dem BSB Handbuch wurde aber genau diese Version verwendet!

Ich habe die Datei "ESP8266 AT Bin V1.7.0" vom 24.08.2018 heruntergeladen. Ist das vielleicht schon falsch?

Schotty

@Bratmaxe: Also ich kann dir da leider nicht weiterhelfen, ich habe es nur so ins Handbuch übernommen, wie freetz es damals beschrieben hatte. Ich habe aber gerade nachgesehen - User 'koblich' hatte auch mal Probleme gemeldet: https://forum.fhem.de/index.php/topic,29762.msg979262.html#msg979262
Bei ihm tauchte auch die Fehlermeldung auf, schien aber trotzdem prinzipiell zu laufen. Empfang stark genug bei dir? Blockt der Router ab? Sorry :(
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

sust

Hallo an alle,

Hab mich nach längererer Zeit mal wieder ins Forum eingelesen.
Und find es u. a. toll das freetz den Adapter renovieren will.
So schlägt er vor den Ausgangstransistor in der Sendeschaltung nicht mehr als Darlington sondern als Collectorschaltung auszuführen.
Sollte man so übernehmen. Erspart einigen Kummer...
Warum aber die Anpassungsschaltung an den Arduino und den Raspberry umgebaut werden soll versteh ich nicht so ganz.
Funktioniert doch wunderbar.
Wollt ihr für die Hardwareserial etwas vorbereiten?
Mit einem USB zu TTl Adapter hab ich sowas via Terminalprogramm mal ausprobiert, hat wunderbar geklappt. Sogar im Paralellbetrieb mit dem Arduino.
Änderungsbedarf deswegen seh ich nicht. Müsste eigentlich auch mit den UARTs des Arduino so klappen.

Wollt ihr Teile sparen? und den Adapter verkleinern? Dann nehmt doch lieber SMD`s. und lasst alles so wie es ist auf der Rechnerseite.

Schaltungstechnisch könnte man bei der Empfangsschaltung den zusätzlichen Transistor ja einsparen, denn der Ausgangstransistor des OK
bietet ja je nach Beschaltung mit Emitterwiderstand oder Collectorwiderstand die Möglichkeit ein nichtinvertiertes oder invertiertes Signal zu erhalten.
Aber nur in der Lötvariante bietet das einen kleinen Platzvorteil und schnell mal umschalten ist dann nicht. 

Gruß sust

freetz

Danke für Deine Anmerkungen, sust. Hintergrund des "Umbaus" ist, dass wir perspektivisch auf einen anderen Microcontroller wechseln müssen, weil die 256kB Speicher einfach nicht mehr ausreichen. Wir sind im Moment bei gut 90% Flash-Auslastung, und auch wenn da noch Einsparpotential drin ist und sich das darüber hinaus auf alle aktivierten "Add-Ons" bezieht, will ich grundsätzlich vorbereitet sein. So wie es aussieht, wird es auf den Arduino Due hinauslaufen, und der läuft wie der Raspberry Pi mit 3,3V. Die bisherige Platine läuft, wenn man sie um einen Pin versetzt einsteckt, zwar auch, aber es wird für den Due noch ein I2C-EEPROM hinzu kommen müssen, und das braucht auch noch Platz, so dass die Platine etwas entschlackt werden muss. Loetmeisters Hinweise waren da sehr hilfreich, auch wenn ich aus eben diesen Platzgründen nicht alles umsetzen können werde, was idealerweise umsetzbar wäre. Denn auf SMD kann und will ich nicht wechseln, weil ich das selber nicht löten kann, und mir das auch von einigen Usern aus dem gleichen Grund vermittelt wurde, dass sie THT bevorzugen.

Jetzt steht noch eine Menge Arbeit am Code bevor, damit dieser auch in Zukunft sowohl auf dem Mega als auch auf dem Due kompiliert, denn zumindest Bugfixes und die aktualisierte _defs.h sollen auch für die Mega-Userschaft verfügbar sein, ohne, dass man sich einen Due kaufen muss.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

sust

Freetz, dann wünsch ich dir viel Spaß bei der Umsetzung.

Gruß Sust

miwi

Falls ein Zwischengesicht hilft, das auf einer Seite mit einer 3.3V-Schaltung und auf der anderen Seite mit einer 5V-Schaltung verbunden wird, da gibt es Loesungen und auch fertige kleine Platinen zu kaufen.

Application Note AN97055
https://cdn-shop.adafruit.com/datasheets/an97055.pdf
https://www.digchip.com/datasheets/parts/datasheet/000/AN97055-pdf.php

AN10441 Level shifting techniques in I2C-bus design
https://www.nxp.com/docs/en/application-note/AN10441.pdf

Circuits:
http://www.hobbytronics.co.uk/mosfet-voltage-level-converter

https://www.elv.de/elektronikwissen/bidirektionaler-pegelwandler.html

Products
https://www.sparkfun.com/products/12009

loetmeister

Zitat von: freetz am 18 Dezember 2019, 23:18:57
Jetzt steht noch eine Menge Arbeit am Code bevor, damit dieser auch in Zukunft sowohl auf dem Mega als auch auf dem Due kompiliert, denn zumindest Bugfixes und die aktualisierte _defs.h sollen auch für die Mega-Userschaft verfügbar sein, ohne, dass man sich einen Due kaufen muss.
Ja, bitte den support für Arduino Mega nicht einstellen  ;)
Grade wenn man nicht alle Funktionen braucht, reicht der Speicher ja gut.
Ich hab in meinem Repository mal pl_start und bus_type in die BSB Klasse aufgenommen, wenn man noch das puzzle mit "len_idx" löst, kann man noch ein paar weitere Byte sparen. https://github.com/fredlcore/bsb_lan/compare/master...loetmeister:master#diff-3949d69f3210e0322e962713a4016f0bL39
Gegen den doppelte Speicher des Due kommt man natürlich nicht an...  ;D

Due
Flash 512 KB
SRAM 96 KB


Mega
Flash 256 KB
SRAM 8 KB


Gruß,
Thomas

loetmeister

#4122
Hallo,

habe mal ein paar Messungen gemacht.
BSB Adapter an meiner Brötje, ca. 4 Meter Netzwerkkabel (ein verdrilltes Adernpaar genutzt). Busspannung 15,3V, 7,6 mA an den Schraubklemmen. Meine extra Schottky-Diode hatte ich weggelassen, somit entspricht die Schaltung auf der Busseite der Vorlage im GitHub.

Dann habe ich noch drei Bilder des Oszilloskops angehängt.
bsb_bus_2 - Signal auf dem Bus (gesendet hat, glaube ich, die Heizung), Teilung 5V und 0,2ms
bsb_ok_2 - Signal hinter dem RX Optokoppler, Teilung 2V und 0,2ms
bsb_ok_3 - Das Gleiche wie zuvor (bsb_ok_2), aber mit 0,1ms Auflösung

Das Signal auf dem Bus ist super, hinter dem Optokoppler ist die fallende Flanke leider nicht gut. Ich würde noch mal eine Messung mit 560k Pulldown an der Basis (pin 6) des Optokopplers machen. Dazu muss der Widerstand wieder drauf, den ich runter genommen hatte. Das schaffe ich wohl erst nach den Feiertagen...

Ergänzung: bzgl der Frage, warum die original Schaltung ohne Basiswiderstand funktioniert, vermutlich filtert die schaltschwelle des nachgelagerten Transistors einen Teil der abfallenden Flanke. (ähnlich eines Schmitt trigger)

Gruß,
Thomas

freetz

Prima, danke, das deckt sich mit meinen (noch nicht per Oszi gemessenen) Erfahrungen. Wenn Du das irgendwann mal mit dem 560k vergleichen könntest, wäre das eine große Hilfe!
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

Schotty

Hatte da nicht Maista auch irgendwann schonmal etwas zu geschrieben? Ich meine, er hatte damals auch andere Werte verwendet, wenn ich mich recht erinnere. Ich finde den Beitrag gerade nicht mehr auf die Schnelle, nur in meinen abgespeicherten Bildern habe ich zwei entdeckt, weiß aber nicht, ob das die darauf bezogenen Schaltpläne sind. Ich hänge sie aber trotzdem mal an..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/