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

[Bauerranger]

@ Luposoft
Der Mega ist über Ethernet verbunden. Konnte bis jetzt den Fehler nicht reproduzieren. Manchmal hält er 12 std. durch oder nur 2 std. Der Mega wurde bei Reichelt gekauft ... denk das des dann kein Clone ist. Momentan bin ich bei 180s. Abfrage Intervall.
Was halt komisch ist das ich mit openhab 2.5 da keine Probleme habe.

Dank schonmal fürs helfen

[Maista]

@ Luposoft
Der Mega ist über Ethernet verbunden. Konnte bis jetzt den Fehler nicht reproduzieren. Manchmal hält er 12 std. durch oder nur 2 std. Der Mega wurde bei Reichelt gekauft ... denk das des dann kein Clone ist. Momentan bin ich bei 180s. Abfrage Intervall.
Was halt komisch ist das ich mit openhab 2.5 da keine Probleme habe.

Dank schonmal fürs helfen

Moin.
Ist den die Spannungsversorgung ausreichend?
Ist das LAN-Shield ebenfalls vom Reichelt?
Ist die LAN-Verbindung in Ordnung?
Ist die Optokoppler Platine korrekt verlötet? Kalte Lötstellen o.ä.?
Gruß Gerd

[sust]

Moin Bauerranger,

Das hört sich nicht so gut an...
Mal sehen was man da per Ferndiagnose so finden kann.

Wenn ich das richtig verstanden hab, ist der Fehler erst mit dem Wechsel von Openhab 2.5 auf 3 aufgetreten.
Also lief der Mega und BSB-Lan zusammen ja schon mal.
Und du nutzt den Mega mit BSB-Lan schon einige Zeit.
Wenn das so ist, ist ein Hardwarefehler zeitgleich mit dem Wechsel zu Openhab 3  eher unwahrscheinlich.

Da du die Konfiguration von Openhab ja prinzipiell beherrscht, schließe ich auch Konfigurationsfehler erstmal aus.

Funktioniert aber dein Webinterface? Funktioniert es so wie vorher? Kannst du was zur Fehlerrate jetzt und früher beim Webinterface sagen?

Wenn du das nicht hier im Forum auseinderpulen magst, dann  kannst mir auch eine Mail schicken.

Ich verwende übrigens auch einen Mega mit der V0.44. Netzwerkverbindung über Lan Shield 5100.
Shield und Mega sind noname clones.
Läuft alles bestens.  Das war aber zu Anfang garnicht so....

Gruß sust

[Bauerranger]

Hallo,

danke für die Hilfestellung. Hab jetzt nochmal ne frische Version aufn den Mega geladen.

Config:



/* Select language; so far German is the most complete, with English following.
* Available languages are: Czech (CS), German (DE), Danish (DA), English (EN), Spanish (ES), Finnish (FI),
* French (FR), Greek (EL), Hungarian (HU), Italian (IT), Dutch (NL), Polish (PL), Russian (RU), Swedish (SV),
* Slovenian (SI) and Turkish (TR).
* Incomplete languages will automagically be filled up with English translations first, and if no English translation
* is available, fallback will take place to German.
*/
#define LANG DE

//#define WIFI  // activate if you are using an ESP8266 AT-firmware based WiFi module
char ssid[] = "Your_WiFi_name_goes_here";            // your network SSID (name)
char pass[] = "Your_WiFi_password_goes_here";        // your network password

/* SECURITY OPTIONS
* There are several options to control and protect access to your heating system. However, keep
* in mind, that even activating all three options are no guarantee that a versatile intruder with
* access to your (W)LAN won't be able to gain access. In any case, no encryption of data streams
* is provided from the Arduino itself. Use VPN or a SSL proxy if that is a must for you and connect
* the Arduino wired to the VPN server or SSL proxy. On the other hand, someone with this amount
* of criminal activity will probably have it easier just to access your heating system face-to-face
*/

/*
* if PASSKEY is defined, the URL has to contain the defined passkey as first element
* e.g.
* http://192.168.178.88/1234/                - to view the main website (don't forget the trailing slash!)
* http://192.168.178.88/1234/K               - to list all categories
* http://192.168.178.88/1234/8700/8740/8741  - to list parameters 8700, 8740 and 8741 in one request
*/
//#define PASSKEY "1234"

/* activate IP-address-based access. Only the last segment of the client's IP address is matched, as it is assumed that
* requests are made from the same subnet only. So if your trusted client's IP is 192.168.178.20, you have to set
* TRUSTED_IP to 20.
*/
//#define TRUSTED_IP 20
//#define TRUSTED_IP2 30

/* activate HTTP-Auth authentification to provide username/password based access. No encryption!
* Default sets username to "atari" and password to "800xl". Visit a website like
* https://www.base64encode.org/
* to encode your own username/password combination in the format username:password
* and replace the YXRhcmk6ODAweGw= string below accordingly.
*/
//#define USER_PASS_B64 "YXRhcmk6ODAweGw="

/* select your heating system (default may work for other systems)
* Set fixed_device_family and fixed_device_variant to your device family and variant (parameters 6225 and 6226) here
* if autodetect does not work or heating system is not running when Arduino is powered on
* You may use other device family numbers to test commands from other heating systems at your own risk
*/
static const int fixed_device_family = 0;
static const int fixed_device_variant = 0;

// Hide unknown parameters from web display (parameters will still be queried!)
//#define HIDE_UNKNOWN

/*
* Define the pin for one wire temperature sensors
*/
//#define ONE_WIRE_BUS 3

// Define the pins for DHT temperature/humidity sensors
//#define DHT_BUS 2,3

// Create 24h averages from these parameters
int avg_parameters[20] = {
  8700,                   // Außentemperatur
  8326                    // Brenner-Modulation
};

/* activate logging on SD-card. Requires a FAT32-formatted Micro-SD card inserted into the Ethernet-Shield's card slot */
//#define LOGGER

int log_parameters[20] = {
//  30000,                  // Logging von "rohen" Bus-Datentelegrammen (macht nur als alleiniger Parameter Sinn)
  8700,                   // Außentemperatur
  8743,                   // Vorlauftemperatur
  8314,                   // Rücklauftemperatur
//  20000,                  // Spezialparameter: Brenner-Laufzeit Stufe 1(/B)
//  20001,                  // Spezialparameter: Brenner-Takte Stufe 1 (/B)
//  20002,                  // Spezialparameter: Brenner-Laufzeit Stufe 2(/B)
//  20003,                  // Spezialparameter: Brenner-Takte Stufe 2 (/B)
//  20004,                  // Spezialparameter: TWW-Laufzeit (/B)
//  20005,                  // Spezialparameter: TWW-Takte (/B)
//  20006,                  // Spezialparameter: 24h-Durchschnittswerte (/A)
//  20101,                  // Spezialparameter 20100-20199: DHT22-Sensoren 1-100 (/T)
//  20200                   // Spezialparameter 20200-20299: DS18B20-Sensoren 1-100 (/T)
};

unsigned long log_interval = 3600;    // logging interval in seconds
boolean log_unknown_only = 1;         // should we log only unknown commands when logging bus telegrams?
boolean log_bc_only = 0;              // should we log only broadcast commands (dest = 0x7f) when logging bus telegrams?

// Activate sending log_parameters to MQTT broker every log_interval seconds
//#define MQTTBrokerIP 192,168,1,20   // Please use commas insteaf of dots!!!
//#define MQTTUsername "User" // Set username for MQTT broker here or comment out if no username/password is used.
//#define MQTTPassword "Pass" // Set password for MQTT broker here or comment out if no password is used.
//#define MQTTTopicPrefix "BSB-LAN" // Optional: Choose the "topic" for MQTT messages here
//#define MQTT_JSON                                                                // Optional: Use this if you want a json package of your logging infomation printed to the mqtt topic
//#define MQTTDeviceID "MyHeater"   // Optional: Define a device name to use as header in json payload. If not defined, BSB-LAN will be used.
// Payload will be of the structure: {"MQTTDeviceID": {"status":{"log_param1":"value1","log_param2":"value2"}, ...}}


// Activate IPWE extension (http://xxx.xxx.xxx.xxx/ipwe.cgi)
#define IPWE

// Parameters to be displayed in IPWE extension
const int ipwe_parameters[] = {
  8700,                   // Außentemperatur
8743,                   // Vorlauftemperatur
  8314,                   // Rücklauftemperatur
  8750,                   // Gebläsedrehzahl
  8830,                   // Warmwassertemperatur
  8740,                   // Raumtemperatur Ist
  8741,                   // Raumtemperatur Soll
  8326,                   // Brenner-Modulation
  8337,                   // Startzähler Brenner
  8703,                   // Aussentemperatur gedämpft
  8704                    // Aussentemperatur gemischt
};

//#define MAX_CUL 192,168,178,5                  // IP of CUNO/CUNX/modified MAX!Cube

const char max_device_list[] PROGMEM = {        // list of MAX! wall/heating thermostats that should be polled
  "KEQ0502326"                                  // use MAX! serial numbers here which have to have exactly 10 characters
  "KEQ0505080"
};

// defines the number of retries for the query command
#define QUERY_RETRIES  3

/* enable /N URL command to reset Arduino - might not work on older boards */
//#define RESET

/*
*  Enter a MAC address, found either on the EthernetShield or use the one below.
*/
static byte mac[] = { 0x00, 0x80, 0x41, 0x19, 0x69, 0x90 };

// Setting bus pins and bus type
// Bus bus (RX pin, TX pin, parameter 3, parameter 4)
// Software Serial needs special pins for RX: 10-13, 50-53, 62(A8)-69(A15)
// W5100 ethernet shield uses the following pins: 10, 50-53
// BSB:
// - optional third parameter sets own address, defaults to 0x42 (LAN in serial monitor)
// - use BSB bus(68,69,6) to define device as RGT1
// LPB:
// - optional third and fourth parameter set own and destination address (high nibble = segment, low nibble = device minus 1)
// - defaults to 0x42 for own address and 0x00 for destination address, i.e. segment 4, device 3 for Arduino/BSB-LAN and segment 0, device 1 for heating system
// PPS:
// - optional third parameter set to "1" enables writing to heater - only use this if there is no other room controller (such as QAA50/QAA70) active. Fourth parameter does not have any effect.
BSB bus(68,69); // BSB bus(19,18); // pin 19,18 = USART Serial1
constexpr uint8_t bus_type = 0;  // set bus system at boot: 0 = BSB, 1 = LPB, 2 = PPS
//#define QAA_TYPE  0x53  // 0x53 = QAA70, 0x52 = QAA50

// Protect these pins from accidental GPIO access
constexpr byte exclude_GPIO[] = {0, 1, 4, 10, 11, 12, 13, 18, 19, 20, 21, 22, 23, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69};

// If set to 1, all messages on the bus are printed to the PC
// hardware serial interface
byte verbose = 1;
byte monitor = 0;

// defines default flag for parameters (use "#define DEFAULT_FLAG 0" to make (almost) all parameters writeable)
#define DEFAULT_FLAG FL_RONLY

// include commands from BSB_lan_custom.h to be executed at the end of each main loop
//#define CUSTOM_COMMANDS

// Check for new versions when accessing BSB-LAN's main page
#define VERSION_CHECK 1

//#define DEBUG
//#define DebugTelnet 1   // Uncomment this to send debug messages to telnet client instead of serial port

//"External" web server. Read files from SD-card. Only static content: html, js, css, jpg, etc.
#define WEBSERVER

/************************************************************************************/
/************************************************************************************/
/* Settings -   END                                                                 */
/************************************************************************************/
/************************************************************************************/

[Maista]

Bitte in Code-Tages stecken.
Das ist meine ich das # im Menü.

[Schotty]

Sieht doch soweit gut aus, von der Seite her sollte es keine Probleme geben.
Nutzt du die "externer Webserver"-Funktion? Falls nicht, dann könntest du das letzte Definement "#define WEBSERVER" noch auskommentieren, also // davor.

[freetz]

Mal wieder eine Frage an die Elektro-Spezis (loetmeister, sust u.a.):
Wir sitzen gerade daran, die BSB-LAN Software auch auf einem ESP32 (https://joy-it.net/de/products/SBC-NodeMCU-ESP32) laufen zu lassen. Grundsätzlich klappt das schon, nur gibt es beim Senden Probleme, die anscheinend nicht an der Software liegen, denn das Oszi zeigt mir, dass die Pegel vom ESP auch an der BSB-LAN Platine ankommen. Nur flackert die LED dann nicht, wie sie es normalerweise beim Arduino tut, bzw. nur sporadisch.
Die GPIOs des ESP32 sollen bis zu 9mA liefern, das ist an sich mehr als das, was der Serial1-TX-Pin des Due liefern soll (3mA), so dass der BC557 Transistor eigentlich schalten müsste.
Auf der anderen Seite speise ich die 3,3V direkt vom 3V3-Pin des NodeMCU ein, und nicht wie beim Due über einen GPIO. Letzeter liefert 15mA, wohingegen der 3V3-Pin deutlich mehr liefern kann. Aber da der Optokoppler am Arduino weiterhin problemlos läuft, ist der Strom nicht so stark, als dass er die OK-LED zerschossen hätte.
Sporadisch scheint es auch mit dem Senden eines Telegramms zu klappen, aber eben sehr unregelmäßig.

Wenn einer von Euch da noch eine zündende Idee hat, würde ich mich sehr freuen!

VG,

F.

[freetz]

Ergänzung: Auch wenn die LED nicht in der Form flackert, wie es bei eingehenden Nachrichten aussieht, kommen die Signale auf der Bus-Seite an. Ich habe nur keinen Logic-Analyzer, der mir die Daten schnell mal dekodieren könnte, ob da auch das richtige ankommt. Das würde zumindest erklären, warum es sporadisch dann doch klappt. Aber mir fehlt weiter der Punkt, an dem ich ansetzen könnte...
EDIT: Die Tests waren bisher über die USB-Stromversorgung meines Macbooks durchgeführt. Wenn ich den NodeMCU ESP32 über USB an meine Synology NAS anschließe, ist die Situation merkbar besser (aber immer noch nicht wirklich gut oder stabil). Könnte das dann doch mit den Vorwiderständen des TX-Optokopplers zu tun haben?

[Maista]

Moin.
Mit einem 1000uF an den 3V3 probiert?

Nachtrag: Der Esp8266 soll beim WLAN-Senden um die 500mA in den Spitzen benötigen.
Deswegen der 1000uF zum auffangen der Stromspitzen.
Ich gehe Mal davon aus das der ESP 32 ähnlich Strom benötigt um WLAN mit entsprechender Leistung bedienen zu können.
Ob der Due mit seiner Spannungsversorgung soviel zusätzlichen Strom abgeben kann hängt daher vom Onhboard Regler ab.

Vielleicht helfen meine Gedanken weiter.

Gruß Gerd

[sust]

Hallo freetz,

Oh, das können sehr viele Dinge sein und den einen sehr wahrscheinlichen Fehler seh ich nicht....

schau mal als 1.:
-betreibst du das Mac Book an 240 V?  auch wenn es ein Apple ist und eigentlich gut und vernünftig designt ist,
Versuch kost nix. Also den Laptop nur mit der geladenen Batterie verwenden. Kein Netzbetrieb.
Bessert sich was?

Dies deutet dann evtl. auf Probleme mit Hochfrequenz vom Schaltnetzteil und oder den Gegenmassnahmen dafür(Ableitungskondensator für die HF gegen einen Nullleiter mit unbekannter Lage) hin.
Und das Zeugs vagabundiert dann durch das gesamte Netzwerk.


Machen sollte man deshalb und eigentlich grundsätzlich dies:
-  Blockt die Versorgungsspannung am Adapter mit 0,1 µF- 2,2µF zw. Versorgungsspannung und GND ab..
-  Baut einen Widerstand von 270K-330K zwischen Basis und Emitter des BC557 ein.
-  Wie hoch ist eigentlich der Pull-Up Widerstand am ESP TX Ausgang ? 10K sind schon eine ganze Menge. Nehmt eher       weniger. Kollidiert das mit dem Vorwiderstand des 557, würd ich eher den Vorwiderstand verkleinern als den Pull-Up zu erhöhen.

Nebenbei: Kann die Diode + Vorwiderstand nicht direkt mit dem Lowpegel vom ESP angesteuert werden?
Pin 1 an +, Pin2 dann über den R an TX1? Wenn der ESP im Low Zustand 5-6mA sicher treiben kann wär das doch kein Problem.

Wenn das nicht reicht versuch auch mal:
-  Baut einen Kondensator von ca. 68 - 330 pF zw. TX und GND ein. (prüfen mit dem Oszi)
Die Größe hängt stark vom tatsächlichen R ab den der Kondensator sieht. Damit wirds leider knifflig wenn für andere was erdacht wird... ).

Den ESP solltest du auch nochmal betrachten. Insbesondere Blockkondensatoren direkt an den Spannungsversorgungspins .und die oben schon schon erwähnten Pull-up/down Widerstände.
Google mal nach "ESP" u. "Frings" da landest du dann wohl auf einer Seite zum ESP8266, die Hinweise sind aber recht interessant und wohl übertragbar auf den ESP32.
Wenn du ein fertiges Board nimmst müsste das eigentlich berücksichtigt worden sein. Schau trotzdem mal genau was da vorgesehen wurde. Wenn da ein Entwickler unterwegs war, der den Batteriebetrieb im Kopf hatte sind die Werte evtl. recht hoch gewählt.

Du hast zwar schon mal das Endgerät getauscht, trotzdem mal ein Problem was von "Hardwareeinzelstücken" ausgelöst werden kann.
Es gibt evtl. ein "Frequenzfensterproblem" bei der seriellen Schnittstelle. Ich kenne das nur vom Mega für den ESP müsstest du das mal im Datenblatt prüfen:
Der Mega hat bei einer UART Datenrate von 115200 Baud und einem Systemtakt von 16MHZ einen systematischen Fehler von +2 %. Wenn der Zufall es will und der Systemtakt des Mega auch noch wegen Quarztoleranz um 1% zu hoch liegt und die Gegenstelle mit der man verbunden ist insgesamt um 1% zu tief liegt, dann kommt man auf insgesamt 4% Abweichung. laut Datenblatt des Mega sind aber nur max 3,5% erlaubt. Empfohlen wird sogar  3%.
Einfachste Abhilfe beim Mega (für dies Zenario) laut Datenblatt: die Taktrate auf 57600 senken dann landet man mit insgesamt 1,2 % Abweichung im grünen Bereich.
Wenn es so eine ähnliche Konstellation auch auf dem ESP gibt, kann zur Prüfung der Fehlerrelevanz  vorläufig eine Taktrate  gewählt werden,  die eine gegensinnige Toleranz aufweist.


Als Nichtprogrammierer die Frage: Die Interrupte am ESP habt ihr im Griff?
Die sollen ja so knifflig sein, weil der ESP so eigenwillig sein soll.
Nicht das die euch die ganzen Taktlängen/Taktpausen versauen.

Der Hinweis von Maista ist gut. Wenn ihr einen 1000µ an der Spannungsversorgung
einbaut, nehmt aber einen mit low ESR und denkt an die Freilaufdiode am Regler, es sei denn im Datenblatt des Reglers wird der Kondensator von 1000µ ausdrücklich zugelassen.

Leider hab ich nicht die Lösung. Ich hoffe das hilft trotzdem ein wenig. Viel Glück

Gruß sust

[freetz]

Danke Euch beiden!

@sust: Ich habe die Tests mit dem Macbook ohne Netzteil (mit halbwegs geladener Batterie) durchgeführt. Die Synology NAS (wo es etwas besser läuft), hat ein "Notebook-Netzteil". Die internen Pullups sollen angeblich 45 kOhm haben, was mir etwas viel vorkommt, aber so steht's im Datenblatt auf S. 43:
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf

Diode und Vorwiderstand direkt vom Low-Pegel treiben - hm, da hatte loetmeister damals den Transistor vorgesehen, damit die LED im OK nicht ständig leuchtet:
https://forum.fhem.de/index.php/topic,29762.msg1002267.html#msg1002267

Ich befürchte aber, dass es am Ende doch eher an der mangelnden direkten Ansteuerung der Pins liegen könnte, denn neben den von Dir genannten Ungenauigkeiten sorgt auch der FIFO beim ESP für Verzögerungen beim Senden und Empfangen. Ich glaube, am Ende werde ich doch nicht um den Logik-Analyzer herumkommen, bzw. einfach mal ein zweites BSB-LAN in den Bus hängen, um zu schauen, ob das die Daten richtig zu Gesicht bekommt...

@Gerd: Danke auch Dir, das mit der Abhängigkeit vom Onboard-Regler hatte ich auch gelesen, aber die Ströme, um die es hier geht, (im einstelligen/niedrigen zweistelligen mA-Bereich) sollten doch eigentlich zu vernachlässigen sein, oder?

[Maista]

Danke Euch beiden!

@sust: Ich habe die Tests mit dem Macbook ohne Netzteil (mit halbwegs geladener Batterie) durchgeführt. Die Synology NAS (wo es etwas besser läuft), hat ein "Notebook-Netzteil". Die internen Pullups sollen angeblich 45 kOhm haben, was mir etwas viel vorkommt, aber so steht's im Datenblatt auf S. 43:
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf

Diode und Vorwiderstand direkt vom Low-Pegel treiben - hm, da hatte loetmeister damals den Transistor vorgesehen, damit die LED im OK nicht ständig leuchtet:
https://forum.fhem.de/index.php/topic,29762.msg1002267.html#msg1002267

Ich befürchte aber, dass es am Ende doch eher an der mangelnden direkten Ansteuerung der Pins liegen könnte, denn neben den von Dir genannten Ungenauigkeiten sorgt auch der FIFO beim ESP für Verzögerungen beim Senden und Empfangen. Ich glaube, am Ende werde ich doch nicht um den Logik-Analyzer herumkommen, bzw. einfach mal ein zweites BSB-LAN in den Bus hängen, um zu schauen, ob das die Daten richtig zu Gesicht bekommt...

@Gerd: Danke auch Dir, das mit der Abhängigkeit vom Onboard-Regler hatte ich auch gelesen, aber die Ströme, um die es hier geht, (im einstelligen/niedrigen zweistelligen mA-Bereich) sollten doch eigentlich zu vernachlässigen sein, oder?

@freetz

Ich bin erst Mal davon ausgegangen daß es vielleicht ein Versorgungsproblem sein könnte.
Was die Pegel der IOs angeht habe ich keine Ahnung.
Habe ich auch nicht im Blick um was es da genau geht
Aber wenn beide ICs mit 3V3 betrieben werden sollten die Ströme der IOs nicht das Problem sein.
Setzt natürlich voraus das die 3V3 stabil sind.
Hattest du die 3V3 mit dem Oszi beobachtet während dem testen?

Manchmal liegt die Lösung so nahe

Gruß Gerd

[freetz]

Danke noch mal für die Tipps - nein, es sieht alles gut aus auf dem Oszi. Allerdings habe ich bei der Gelegenheit das Oszi mal auf der BSB-Seite genauer angesehen und da fiel mir auf, dass zwischen jedem Byte eine Pause von 50ms lagen. Beim Arduino schicke ich jedes Byte einzeln auf den Bus und sorge mit einem flush() dafür, dass das Programm auch so lange wartet. Das scheint beim ESP32 ein Problem (in diesem Zusammenhang) zu sein, da muss ich erst mal alles in den FIFO schieben, dann klappte es auch. Bei PPS war es ähnlich gelagert, da wird beim Empfangen erst mal gewartet, bis 112(!) Zeichen im Buffer sind oder über den Zeitraum von zwei Zeichen keine Daten empfangen werden. Zu viel für den zeitkritischen PPS-Bus. Jetzt klappt es bei allen dreien und es sieht nicht so aus, als müsste ich an der Hardware etwas ändern. Vielen Dank Euch auf jeden Fall für die Unterstützung!

Wer will, kann mit der BSB-LAN-Platine ab V3 auch schon einmal den Einsatz am ESP32 probieren. Der Code dafür ist im Master-Repository auf GitHub hinterlegt, Probleme gibt es noch bei der Web-Config und an ein paar anderen kleineren Baustellen, aber ansonsten funktioniert das Auslesen und Setzen von Parametern schon recht stabil.

[Schotty]

Wer will, kann mit der BSB-LAN-Platine ab V3 auch schon einmal den Einsatz am ESP32 probieren. Der Code dafür ist im Master-Repository auf GitHub hinterlegt, Probleme gibt es noch bei der Web-Config und an ein paar anderen kleineren Baustellen, aber ansonsten funktioniert das Auslesen und Setzen von Parametern schon recht stabil.

Würde ich gerne, aber nach wie vor kommt beim Kompilieren mit der Arduino IDE die im Issue erwähnte Fehlermeldung (unabhängig davon, welchen ESP32-Boardtyp ich auswähle).

Code Auswählen Erweitern


BSB_lan:6305:23: error: conflicting declaration of 'void loop()' with 'C' linkage
In file included from /tmp/arduino_build_242246/sketch/src/BSB/bsb.h:6:0,
                 from /home/db/BSB_lan/BSB_lan.ino:439:
/home/db/.arduino15/packages/esp32/hardware/esp32/1.0.4/cores/esp32/Arduino.h:119:6: note: previous declaration with 'C++' linkage
void loop(void);
      ^

...

exit status 1
conflicting declaration of 'void loop()' with 'C' linkage


[marko-79]

Ich benutze einen BSB Adapter mit angeschlossen DS18B20 Sensoren. Wenn ich in der Config das loggen aktiviere sind dann die einzelnen Sensoren per http-abfrage im Format http://<meineip>/20200 verfügbar?
Wenn nein welche Möglichkeiten gibt es? Möchte die Sensoren in ioBroker einbinden.