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

[freetz]

Nein, es ist nicht hoffnungslos und es ist grundsätzlich auch kein Problem. Du kannst auf jeden Fall die beiden i2C-Pins nehmen (GPIO 13 und GPIO 16), U1RXD (GPIO 36) sollte auch gehen, wobei Du dann schauen müsstest, ob der Olimex reibungslos bootet, denn GPIO36 muss während des Bootens (mehr oder weniger) auf Masse gezogen sein. Wenn der Widerstand durch den Sensor zu groß ist, könnte das ein Problem sein. Wenn Du die Micro-SD-Karte nicht verwendest, dürften auch die GPIOs 2, 14 und 15 gehen. Das gleiche gilt für den CAN-Bus-Anschluss (GPIOs 5 und 35), wobei Pins 5 und 15 "Bootstrapping-Pins" sind, die mit Pull-Up-Widerständen versehen sind. Ob das ein Problem ist oder nicht, hängt von dem verwendeten Sensor ab.

Es wäre prima, wenn Du uns nach einem Test mal Rückmeldung geben könntest, mit welchen Pins es zuverlässig funktioniert.

[Schotty]

@nols
Nur als Tipp:

1) Wenn du auf Feuchtigkeitsmessungen verzichten kannst, setze die gekapselten DS18B20 ein.
Vorteile: Feuchtigkeitsunempfindlich/wasserdicht, du brauchst nur einen Pin für DATA, kannst aber trotzdem aufgrund des 1Wire-Bus zig Sensoren ganz leicht einbinden bzw auch nachträglich noch hinzufügen (siehe hier auch den Bauvorschlag bzgl 'Verteiler' am Ende des DS18B20-Kapitels), lassen sich außerdem auch im Bereich der Heizungsinstallation vielfältig an Rohren oder in den Fühlerhülsen bei Pufferspeichern etc einsetzen (siehe Tipps/Hinweise im Handbuch).

2) Wenn du Feuchtigkeit mit messen und eh den I2C-Anschluss nehmen willst, denk über BME280 nach.
Vorteile: Sind angeblich genauer als DHT22, liefern zusätzlich noch Luftdruck (was du ggf für ne Wettervorhersage oder so noch nutzen kannst), du kannst bis zu zwei Sensoren am I2C anschließen (bzw bis zu 16 mit nem zusätzlichen TCA9548A-Multiplexer, das habe ich im Handbuch noch nicht erwähnt, hole ich nach).
Nachteil: Gibt's nicht in so einem Gehäuse wie die DHT22/AM2302, sprich, die Platine&Elektronik liegt eher frei - dem könntest du aber notfalls mit ner Bastellösung abhelfen.

3) Wenn DHT22: Denk dran, dass du für JEDEN DHT22, den du anschließen willst, einen eigenen Pin für DATA brauchst. Willst du also drei DHT22 nutzen, brauchst du auch drei freie Pins.

Rückmeldung ist, wie freetz schon sagte, sehr willkommen!

[DukeSS]

@nols

There is another way: I have added support for BLE (Bluetooth Low Energy) sensors for ESP 32. This support is absent in the main branch because the BLE stack takes up a lot of space and, for example, the OTA stops working.

BSB-LAN with BLE: https://github.com/dukess/BSB-LAN/tree/BLE-sensors
Supported sensors: https://github.com/pvvx/ble_monitor (I use LYWSD03MMC sensors)
Limitations: right now advertisement messages with encryption not supported so you should use the alternative firmware for sensors https://github.com/pvvx/ATC_MiThermometer

[Schotty]

Right! I need to add that solution to the manual! Thanks for the reminder

EDIT:
I now listed this 'unofficial' solution here:
DE: https://1coderookie.github.io/BSB-LPB-LAN/kap07.html#744-xiaomi-mijia-ble-sensoren
EN: https://1coderookie.github.io/BSB-LPB-LAN_EN/chap07.html#744-xiaomi-mijia-ble-sensors

[loetmeister]

Hallo,

habe mal versucht meinen zweiten Mega 2560 mit der aktuellen 2.x Version zu nutzen... es sieht schon mal nicht sooo schlecht aus, mit der alten Gerätefamilie, die ich von der alten 1.x Version ausgelesen und mit selected_defs.exe 163 > BSB_LAN_defs_filtered.h gefiltert habe scheint aber noch was nicht zu passen...
Alte Ausgabe von /Q
Teste Geräteadresse 0:
Gerätefamilie: 163
Gerätevariante: 5
Geräte-Identifikation: LMS15.003A100

Nun kommt immer "query failed"... kann es sein das mit selected_defs.exe 163 zu viel herausgefiltert wurde?
Ein diff von BSB_LAN_defs_filtered.h und BSB_LAN_defs.h (dem original) hat mich so direkt nicht weiter gebracht.... wo könnte ich schauen? 

Code: [Auswählen]

Hardware: Mega 2560
Version: 2.1.0-20211231181308
Freier Speicher: 2600 Bytes
Uptime: 295113
1-Wire Bus Pins: 3, Sensoren: 1

Installierte Module:
Verbose DEBUG, ONE_WIRE_BUS, CONFIG_IN_EEPROM, WEBCONFIG
Bus Kommunikation ist eigentlich ok:

Code: [Auswählen]

HEIZ->DSP1 ANS 8310 Diagnose Erzeuger - Kesseltemperatur: 39.7 °C
DC 80 0A 0E 07 0D 3D 05 19 00 09 EA 59 77
GET /K0 HTTP/1.1
 query failed
 query failed
0
...
 query failed
6225
 query failed
 query failed
6226

JSON

Code: [Auswählen]

{
  "6226": {
    "name": "Gerätevariante",
    "dataType_name": "UINT",
    "dataType_family": "VALS",
    "error": 261,
    "value": "",
    "desc": "",
    "precision": 1,
    "dataType": 0,
    "readonly": 1,
    "readwrite": 1,
    "unit": ""
  },
  "6225": {
    "name": "Gerätefamilie",
    "dataType_name": "UINT",
    "dataType_family": "VALS",
    "error": 261,
    "value": "",
    "desc": "",
    "precision": 1,
    "dataType": 0,
    "readonly": 1,
    "readwrite": 1,
    "unit": ""
  }
  "8310": {
    "name": "Kesseltemperatur",
    "dataType_name": "TEMP",
    "dataType_family": "VALS",
    "error": 261,
    "value": "",
    "desc": "",
    "precision": 0.1,
    "dataType": 0,
    "readonly": 1,
    "readwrite": 1,
    "unit": "°C"
  }
}
Was auch komisch aussieht, ist die /C Seite. Die ersten beiden Optionen werden wie folgt angezeigt:
Generellhema TrinkwasserspeicherErweiterte Einstellungen anzeigenhema Trinkwasserspeicher

Generellhema TrinkwasserspeicherKonfiguration aus EEPROM lesenhema Trinkwasserspeicher

Gruß,
Thomas

[freetz]

Hm, ich habe wie gesagt kein Mega2560-Testsystem mehr am Laufen, von daher kann ich dazu nichts Konkretes sagen, aber "query failed" hat erst einmal nichts mit der _defs.h zu tun. Du könntest das überprüfen, indem Du die Standardinstallation nimmst und alles, bis auf die Parameter 6225 und 6226 rausnimmst. Dann sollte zumindest die Gerätefamilie und -variante erkannt werden.
Ich vermute aber mal, dass das nicht klappt und der Fehler irgendwo im TX-Pfad liegt. Denn dass Du Daten vom Bus sehen kannst, zeigt nur, dass der RX-Pfad in Ordnung ist (was ja schon mal gut ist), sagt aber nichts über den TX-Pfad aus.

Die verwurschtelten Texte deuten auf ein Speicherproblem hin, vermutlich ist die Firmware immer noch zu groß.
Auch wenn ich den Einsatz für den Mega bewundere und ich ja auch sehr dafür bin, alte Hardware möglichst lange zu nutzen, aber in dem Fall muss man sich eben mit der 0.44 oder ggf. 1.x begnügen. An den ESP32-Varianten, die wir unterstützen, lässt sich prinzipiell auch noch ein alter Adapter weiterverwenden. Das ist dann der entspanntere Weg, und den Mega kann man vielleicht noch für andere Dinge verwenden...

[Schotty]

@loetmeister
Falls du an der v2+ESP32-Lösung Interesse hast, hier findest du die entspr Infos dazu: https://1coderookie.github.io/BSB-LPB-LAN/kap01.html#133-esp32-mit-veraltetem-bsb-lan-adapter-v2

[loetmeister]

Danke für die Hilfe. Vermutlich bleibe ich bei 1.x ... ich wollte mir aber mal die Einstellungen mit EEPROM ansehen, das fände ich schön da flexibler zu sein als alles fest im Code zu haben.
Das zweite ist ein kleines Problem bei meiner 1.1, das dort "desc" leer ist, es sollte aber "Keine Funktion" stehen (ENUM5890_2_00_TEXT in dem speziellen Fall)
Da wollte ich sehen wie sich 2.x verhält...

Code: [Auswählen]

HEIZ->LAN ANS 8304 Diagnose Erzeuger - Kesselpumpe Q1: ---
DC 80 42 0D 07 05 3D 09 A2 01 00 24 0E

  "8304": {
    "name": "Kesselpumpe Q1",
    "error": 0,
    "value": "---",
    "desc": "",
    "dataType": 1,
    "readonly": 1,
    "unit": ""
  }
Das beschriebene "query failed" Problem in 2.1 habe ich erst mal gelöst, in dem ich bsb.cpp & bsb.h von 1.1 genommen habe.
So reicht es erst mal, um zu prüfen ob die JSON Ausgabe besser funktioniert...

Gruß,
Thomas

[freetz]

Oh, interessant, könntest Du mal ein Diff der beiden Versionen machen, damit ich sehen kann, worin genau der entscheidende Unterschied liegt? Denn grundsätzlich will ich ja nicht verhindern, dass die Software auch theoretisch auf dem Mega laufen könnte. Wenn sich da also im Zuge der Anpassungen für den Due oder ESP32 etwas eingeschlichen hat, was vermeidbar wäre, dann passe ich das natürlich gerne entsprechend an...

[DukeSS]

First version worked with my Mega until about the middle of last summer.

[DukeSS]

@freetz
The main difference is the improvement (adding code) to the collision detector.

[freetz]

Ok, but still the exact code difference would be helpful to see if it's necessary for the current platforms or not. If it's no more than a few lines of code, then I'd be fine to still support it, but no more cluttering of the code anymore - especially if other things are no longer working as well. Sometimes it's just time to say goodbye ...

[DukeSS]

Did it in temporary branch: https://github.com/dukess/BSB-LAN/commit/864f2dc10e35d3fbee30e20427a5cde144914d42

[freetz]

Thanks - hmm, I still wonder why it creates a problem on the Mega and not on the Due. But those changes were necessary for the ESP32, so we won't be able to revert easily back to the old code. At least not without cluttering the file with more #ifdefs...

[DukeSS]

It seems to me delays is blame in this behavior.

Lazy solution: we can copy old bsb.cpp as bsb-mega.cpp and add macros for compilation prevention.