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

[crazykiwi]

Hallo zusammen,

ich habe derzeit BSB-LAN auf einem NodeMCU laufen. Verbunden ist dieser via BSB mit einem Brötje Solarsystemregler (ISR-SSR), an dem wiederum ein Ölbrenner (BOB25) und Solarthermie hängen. Ich bin ursprünglich davon ausgegangen, dass der ISR-SSR alle Daten der Geräte die am Bus hängen sammelt, und ich alle Daten dort abfragen kann. Leider funktioniert das so bekanntermaßen nicht - die Brennerlaufzeiten (Stufe 1 und 2) und z.B. Anlagendruck sehe ich nur am Brenner. Diese sind mir aber enorm wichtig, vor allem die Laufzeiten für eine Berechnung des Ölverbrauchs. Komme ich jetzt nicht umhin, mir einen zweiten Adapter an den Brenner zu hängen, oder könnte ich via LPB unkompliziert beide Geräte abfragen?
Aus den bisherigen Einträgen bzw. dem Handbuch konnte ich nicht zweifelsfrei erkennen, ob eine "gleichzeitige" Abfrage (d.h. ständiger automatischer Wechsel) von zwei Geräten möglich ist, bzw. wie ich die entsprechenden Adressierungen überhaupt herausfinden kann...

Aus genannten Gründen würde ich jetzt versuchen, von BSB auf LBP zu wechseln. Ist dann auch zwingend eine neue BSB_LAN_custom_defs.h zu erstellen?

[freetz]

Sorry für die späte Rückmeldung - das mit den hin und wieder ausbleibenden Benachrichtigungen im Forum hier ist unschön...
Nein, dann haben wir aneinander vorbeigeredet. Wenn Du unter Tools->Board den EVB ausgewählt hat, sollte alles richtig sein. Und wenn es jetzt mit der 0 bei den Pins klappt und damit auch die Auto-Detection läuft, dann wird sich wohl vorher irgendwas verhakt haben. Aber wie gesagt, die Autodetection sollte laufen, damit Du bei zukünftigen Updates auch auf der sicheren Seite bist.

[freetz]

@crazykiwi: Ja, in dem Fall empfiehlt es sich, eine neue Datei von mir erstellen zu lassen.

[freetz]

@aViN187: Hattest Du mir Deine Liste eigentlich schon geschickt? Falls ja, dann finde ich sie gerade nicht mehr (bzw. kann Deinen Usernamen nicht zu einer Mail zuordnen), dann schick' sie mir bitte noch mal...

[sponk]

Moin zusammen,

Frage an alle User mit DS18B20 im Betrieb:

Wie habt ihr das Thema mit der Re-Adressierung gelöst?

Im Handbuch ist angemerkt, dass man damit Probleme bekommt, aber ich habe das mangels einfacher Möglichkeiten ignoriert und direkt die Parameter 20300.1 und folgende weiterverwertet. Dachte auch, dass die Sensoren schon eine Weile halten. Jetzt macht aber bereits der erste sporadisch Probleme (ausgerechnet auch noch der 20300er), so dass ab und an alle Sensoren eins durchrutschen und dann die Datenreihen Sprünge macht...

Als einfachstes dachte ich daran die Temmperaturen nach Prüfung der SensorID auf die custom_floats umzumappen. Wenn 20300 Sensore-ID passt > schreibe 20300.1 auf 207XX. Allerdings scheiter ich schon daran, die Werte aufzurufen? Vllt kann mir da einer nen Hinweis geben, wie ich die 20300 aufrufen kann? Die floats gehen ja direkt mit custom_floats[0]...

Vollständigkeitshalber mein Setup: BSB-Lan >> MQTT >> Telegraf >> InfluxDB
Ich denke das sauberste wäre halt die DS18B20 schon in eindeutiger Form weiterzugeben. Ansonsten könnte ich das höchstens noch im Telegraf richten, aber das erscheint mir komplizierter, außerdem müsste ich immer die SensorID mitschleifen.

Danke, Gruss

[freetz]

Also ich nutze diese Sensoren selber nicht, aber das Ummappen könntest Du das, was Du beschreibst relativ einfach über die _custom.h erledigen, indem Du mit switch/case die Sensor-IDs abfragst (die BSB_LAN-Funktion heißt "query()") und dann mit set() die custom_floats entsprechend setzt.
Alternativ kannst Du auch die IPWE-Funktion verwenden, da bekommst Du ja die Ausgabe in Tabellenform, wo jeder Sensor in einer Zeile angezeigt wird. Die kann man relativ einfach parsen (bei FHEM mit HTTPMod) und das dann zuordnen. So habe ich es zu Beginn längere Zeit gemacht.

[sponk]

Danke freetz, so hatte ich das auch im Sinne. Besten Dank für den schnellen Hinweis mit dem query(), läuft schon im Testmodus:-)

Hier mein Snippet, wen es interessiert:

Code Auswählen Erweitern

///////// DS18B20 sortieren

for (int i = 0; i < 5; i++) {
  query(20300+i);
  DS18B20_ID = decodedTelegram.value;
  // Serial.print(DS18B20_ID);
  // Serial.print(": ");

  if (DS18B20_ID == DS18B20_ID_Brenner) {
    // Serial.println("DS18B20_ID_Brenner");
    query(20300.1+i);
    // Serial.println(decodedTelegram.value);
    custom_floats[10]=atof(decodedTelegram.value);
  }

  else if (DS18B20_ID == DS18B20_ID_HK_Vorlauf) {
    // Serial.println("DS18B20_ID_HK_Vorlauf");
    query(20300.1+i);
    // Serial.println(decodedTelegram.value);
    custom_floats[11]=atof(decodedTelegram.value);
  }

  else if (DS18B20_ID == DS18B20_ID_HK_Ruecklauf) {
    // Serial.println("DS18B20_ID_HK_Vorlauf");
    query(20300.1+i);
    // Serial.println(decodedTelegram.value);
    custom_floats[12]=atof(decodedTelegram.value);
  }

  else if (DS18B20_ID == DS18B20_ID_Speicher) {
    // Serial.println("DS18B20_ID_HK_Vorlauf");
    query(20300.1+i);
    // Serial.println(decodedTelegram.value);
    custom_floats[13]=atof(decodedTelegram.value);
  }

  else if (DS18B20_ID == DS18B20_ID_WW_Entnahme) {
    // Serial.println("DS18B20_ID_HK_Vorlauf");
    query(20300.1+i);
    // Serial.println(decodedTelegram.value);
    custom_floats[14]=atof(decodedTelegram.value);
  }

  else {
    // Serial.println("keine Übereinstimmung");
  }
}

und in der BSB_LAN_custom_global.h:

Code Auswählen Erweitern

const String DS18B20_ID_Brenner = "28186481E3E13C33";
const String DS18B20_ID_HK_Vorlauf = "28A2FB81E3E13C23";
const String DS18B20_ID_HK_Ruecklauf = "28619381E3E13CCA";
const String DS18B20_ID_Speicher = "28B3B181E3E13C1B";
const String DS18B20_ID_WW_Entnahme = "28AD8E81E3E13CB8";


[freetz]

Danke für's Teilen der Lösung! Ich wusste gar nicht, dass man einen char-Pointer einfach über "==" mit einem String auf Übereinstimmung überprüfen kann .
Würde das hier dann auch funktionieren (und vielleicht etwas übersichtlicher sein)?

Code Auswählen Erweitern

for (int i = 0; i < 5; i++) {
  query(20300+i);
  long long DS_Addr = std::stoll(decodedTelegram.value);
  query(20300.1+i);

  switch(DS_Addr) {
    case (0x28186481E3E13C33): // Brenner
      custom_floats[10]=atof(decodedTelegram.value);
      break;
    case (0x28A2FB81E3E13C23): // HK Vorlauf
      custom_floats[11]=atof(decodedTelegram.value);
      break;
    case (0x28619381E3E13CCA): // HK Rücklauf
      custom_floats[12]=atof(decodedTelegram.value);
      break;
    case (0x28B3B181E3E13C1B): // HK Speicher
      custom_floats[13]=atof(decodedTelegram.value);
      break;
    case (0x28AD8E81E3E13CB8): // WW Entnahme
      custom_floats[14]=atof(decodedTelegram.value);
      break;
    default:
      Serial.print("keine Übereinstimmung für ID ");
      Serial.println(DS_Addr, HEX);
  }
}

Wäre nett, wenn Du das mal testen könntest, dann wäre das ein Beispiel für die _custom.h Bibliothek.

[sponk]

Moin,
jaa das sieht schon etwas eleganter aus. In meinem Testsetup (mit zwei DS18B20 und anderen ID's) funkioniert es aber leider nicht. Da klappt irgendwas mit der Umwandlung nicht und man muss wohl eine leere query noch abfangen:

Hier der (zum Debugging) leicht abgeänderte Code:

Code Auswählen Erweitern

for (int i = 0; i < 5; i++) {
  query(20300+i);
  Serial.println(decodedTelegram.value);
  long long DS_Addr = std::stoll(decodedTelegram.value);
  Serial.println(DS_Addr);
  query(20300.1+i);
  Serial.println(decodedTelegram.value);

  switch(DS_Addr) {
    case (0x28616408EB7E2EA8): // Brenner
      custom_floats[10]=atof(decodedTelegram.value);
      break;
    case (0x28616408EB4370C8): // HK Vorlauf
      custom_floats[11]=atof(decodedTelegram.value);
      break;
    case (0x28619381E3E13CCA): // HK Rücklauf
      custom_floats[12]=atof(decodedTelegram.value);
      break;
    case (0x28B3B181E3E13C1B): // WW Speicher
      custom_floats[13]=atof(decodedTelegram.value);
      break;
    case (0x28AD8E81E3E13CB8): // WW Entnahme
      custom_floats[14]=atof(decodedTelegram.value);
      break;
    default:
      Serial.print("keine Übereinstimmung für ID ");
      //Serial.println(DS_Addr, HEX);
  }
}

und der Serialmonitor:

Code Auswählen Erweitern

09:09:34.525 -> Starting MDNS service with hostname BSB-LAN3
09:09:34.525 -> Setup complete
09:09:34.525 -> Client ID: BSB-LAN_Tester_BB
09:09:34.525 -> Will topic: BSB-LAN_Tester_BB/status
09:09:34.558 -> Connect to MQTT broker, updating will topic
09:09:34.558 -> Subscribed to topic 'BSB-LAN_Tester_BB'
09:09:34.558 -> Published status 'online' to topic 'BSB-LAN_Tester_BB/status'
09:09:34.558 -> One Wire, DHT & MAX! Sensors
09:09:34.558 -> Virtual parameter 20300 queried. Table line 113
09:09:34.558 -> 28616408EB7E2EA8
09:09:34.589 -> 28616408
09:09:34.589 -> One Wire, DHT & MAX! Sensors
09:09:34.589 -> Virtual parameter 20300.1 queried. Table line 114
09:09:34.589 -> 19.56
09:09:34.589 -> keine Übereinstimmung für ID One Wire, DHT & MAX! Sensors
09:09:34.621 -> Virtual parameter 20301 queried. Table line 113
09:09:34.621 -> 28616408EB4370C8
09:09:34.621 -> 28616408
09:09:34.621 -> One Wire, DHT & MAX! Sensors
09:09:34.621 -> Virtual parameter 20301.1 queried. Table line 114
09:09:34.691 -> 19.62
09:09:34.691 -> keine Übereinstimmung für ID
09:09:34.691 ->
09:09:34.691 -> abort() was called at PC 0x401562c3 on core 1
09:09:34.691 ->
09:09:34.691 ->
09:09:34.691 -> Backtrace:0x40083d5d:0x3ffb23f00x4008d1dd:0x3ffb2410 0x400926a1:0x3ffb2430 0x401562c3:0x3ffb24b0 0x4015630a:0x3ffb24d0 0x40155f3f:0x3ffb24f0 0x4015608b:0x3ffb2510 0x400dff36:0x3ffb2530 0x400eecc1:0x3ffb2820
09:09:34.691 ->
Ich habe das mit etwas rumprobieren nicht zum Laufen bekommen  ("" zum Abfangen der leeren query, oder std::stoll(28616408EB7E2EA8)...)

[JHx]

Hallo miteinander,

leider hat sich mein Problem mit den Ausfällen immer noch nicht gelöst. Bisher ist der Fehler nicht mehr aufgetreten, was aber vermutlich daran liegt, dass die Heizung bis jetzt im Sommerbetrieb war und nicht angesprungen ist. Nun habe ich festgestellt, dass BSB-LAN sporadisch, aber immer im Zusammenhang mit dem Brennerbetrieb ausfällt. Gestern abend hat der Brenner den Kessel drei mal aufgeheizt, jeweils mit ca. 20 min. Pause zwischen den Vorgängen. Hier trat kein Fehler auf. Um ca. 22:00 Uhr hat die Heizung dann in den Absenkbetrieb geschaltet, die Pumpen gingen aus. Heute morgen wurde per Zeitschaltung der Komfortbetrieb ab 6:00 Uhr aktiviert. Im BSB-LAN-Adapter vom ioBroker habe ich dann heute morgen gesehen, dass BSB-LAN ab 6:22 Uhr nicht mehr erreichbar war. Nachdem ich die Spannungsversorung vom BSB-LAN bzw. vom Olimex EVB getrennt und wieder verbunden habe, ist das BSB-LAN wieder erreichbar. Folgendes habe ich bereits geprüft/geändert:
1. Die Stromversorgung läuft über eine andere Phase, als die der Heizung.
2. Das Netzteil habe ich von 1,5A auf 2,0A getauscht.
Was kann ich tun, um das Problem weiter einzukreisen? Laptop vie Serial-Monitor an den BSB-LAN anschließen und beochachten? Worauf kann/muss ich hierbei achten?

VG Jürgen

[freetz]

@sponk:
Hm, die IDs hatte ich aus Deinem Code vorher übernommen, wieso sind die jetzt anders?
Aber trotzdem hast Du Recht, da sind noch zwei Fehler im Code gewesen:
Zum einen muss DS_Addr nicht als "long long", sondern als "unsigned long long" definiert werden, zum anderen geht std::stoll defaultmäßig von einer Dezimalzahl aus, aber die IDs sind ja hexadezimal abgespeichert.
Die Zeile muss also

Code Auswählen Erweitern

  unsigned long long DS_Addr = std::stoll(decodedTelegram.value, NULL, 16);
lauten.
Kannst Du es damit noch mal testen?

[freetz]

@JHx: Die reine Amperezahl sagt nicht zwingend etwas über die Qualität aus. Wichtig(er) ist, dass auch die Spannung konstante 5V liefert. Falls Du darüber hinaus WLAN einsetzt, deaktiviere bitte den Energiesparmodus in den Einstellungen von BSB-LAN.
Ansonsten solltest Du ein Log mit Zeitstempel mitlaufen lassen und schauen, ob sich die Aussetzer zuordnen lassen. Es kann z.B. auch sein, dass es "nur" ein Netzwerkproblem ist, aber BSB-LAN weiter läuft. Wir hatten das Problem schon mal bei einem User, bei dem BSB-LAN am LAN-Port eines Fritz-Repeaters hing. Bei einer direkten LAN-Verbindung oder direkt per WLAN traten die Probleme dann nicht mehr auf.
Aber wie gesagt, es müsste schon ein reproduzierbares Verhalten sein, damit man aus der Ferne überhaupt irgendwas sagen kann...

[sponk]

Die ID's sind anders, weil ich es an einem Test-setup mit zwei anderen DS18B20 teste. Ist also im Prinzip der Fall simuliert, dass 3x DS18B20 nicht funktionieren.

Die Zuordnung funktioniert jetzt. Allerdings stürzt das Board immer noch ab, wenn der Parameter nicht gefunden wird und damit das Telegram leer (?) ist. Ich vermute, dass die Umwandlung Probleme macht?
Komischerweise endet der serial log aber nicht mit der Ausgabe der query 20302 !?

Code Auswählen Erweitern

10:42:22.978 -> Starting MDNS service with hostname BSB-LAN3
10:42:22.978 -> Setup complete
10:42:22.978 -> Client ID: BSB-LAN_Tester_BB
10:42:23.014 -> Will topic: BSB-LAN_Tester_BB/status
10:42:23.014 -> Connect to MQTT broker, updating will topic
10:42:23.014 -> Subscribed to topic 'BSB-LAN_Tester_BB'
10:42:23.014 -> Published status 'online' to topic 'BSB-LAN_Tester_BB/status'
10:42:23.014 -> One Wire, DHT & MAX! Sensors
10:42:23.014 -> Virtual parameter 20300 queried. Table line 113
10:42:23.046 -> 28616408EB7E2EA8
10:42:23.046 -> 2909716823731482280
10:42:23.046 -> One Wire, DHT & MAX! Sensors
10:42:23.046 -> Virtual parameter 20300.1 queried. Table line 114
10:42:23.046 -> 20.37
10:42:23.046 -> One Wire, DHT & MAX! Sensors
10:42:23.079 -> Virtual parameter 20301 queried. Table line 113
10:42:23.079 -> 28616408EB4370C8
10:42:23.079 -> 2909716823727632584
10:42:23.079 -> One Wire, DHT & MAX! Sensors
10:42:23.112 -> Virtual parameter 20301.1 queried. Table line 114
10:42:23.145 -> 20.56
10:42:23.145 ->
10:42:23.145 ->
10:42:23.145 -> abort() was called at PC 0x401562b7 on core 1
10:42:23.145 ->
10:42:23.145 ->
10:42:23.145 -> Backtrace:0x40083d5d:0x3ffb23f00x4008d1dd:0x3ffb2410 0x400926a1:0x3ffb2430 0x401562b7:0x3ffb24b0 0x401562fe:0x3ffb24d0 0x40155f33:0x3ffb24f0 0x4015607f:0x3ffb2510 0x400dff36:0x3ffb2530 0x400eecb9:0x3ffb2820
10:42:23.178 ->


[freetz]

Du scheinst die Debug-Ausgabe der ID, die dann nicht gefunden wird, im default: branch des switch-Blocks auskommentiert zu haben, oder? Ich vermute, dass decodedTelegram.value etwas enthält, was nicht verarbeitet werden kann. Die Frage ist, was das ist, bzw. welche Zeile dann den Absturz auslöst. Ich setze mir in diesen Fällen auf die Schnelle einfach ein paar Serial.println()-Zeilen mit aufsteigenden Zahlen in den Code, um dann zu sehen, bis wohin es noch geht. Dann kann man anhand der auslösenden Zeile besser schauen, wie man das umgehen kann...

[sponk]

Das hatte ich nur testweise auskommentiert, weil ich dachte es liegt vllt an der HEX Ausgabeanforderung für Serielprint(?).

Code Auswählen Erweitern

for (int i = 0; i < 5; i++) {
  Serial.println(i);
  query(20300+i);
  Serial.println(decodedTelegram.value);
 
  unsigned long long DS_Addr = std::stoll(decodedTelegram.value, NULL, 16);
  Serial.println(DS_Addr);
  query(20300.1+i);
  Serial.println(decodedTelegram.value);

Bei dem Teilcode wird das erste serial print (i) noch ausgeführt, das 2. Serial print des Telegrams nicht mehr. Das heisst ja eigentlich es müsste die query sein. Die läuft aber in meinem og Code (auch für die existenten Sensoren ab 20302). Daher dachte ich es muss das nächste sein, das ist die Umwandlung. Hast du da noch eine Idee?