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

[acfischer42]

@freetz,

sorry, kannst Du noch mal schauen? in der Letzten github version ist es noch

0x2E3D0572,

und nicht

0x2E3E0572,    (es geht ums E)

Das E habe ich mir aus dem Telegramm selber ausgedacht, ich will nur sicher gehen welcher Code stimmt.

danke
Achim

[freetz]

Hab' ich noch mal geändert, aber ich Deine Mitschnitte zeigen, dass der Error 7 woanders her kommt:
Das Setzen sowohl von Parameter 1001 als auch 701 (jeweils 1. Zeile, "SET", Typ 03) wird gleich darauf mit einem ACK (Typ 04) beantwortet. D.h., die Therme hat den Befehl angenommen und umgesetzt.
BSB-LAN geht aber bei einem SET-Befehl noch einen Schritt weiter und ruft den gerade gesetzten Parameter noch einmal ab (QUR, Typ 06). Dies wird anscheinend nicht unterstützt, weshalb Du einen Typ 08 (ERR) zurückgemeldet bekommst. Schotty und ich bekommen bei 701 zwar keinen Error, aber auch keine sinnvollen Werte auf den Query zurück gemeldet, so dass eine Abfrage dieses Wertes wohl nicht vorgesehen ist, ähnlich wie es bei INF-Parametern (wie z.B. 10000) auch der Fall ist.

Zusammengefasst bedeutet das, dass man sich auf die Rückgabewerte von 701 und 1001 nicht verlassen kann, und diese entweder ignoriert oder gleich als INF-Telegramme mit z.B. /I701=x verschickt, da hier dann keine erneute Abfrage des Parameters erfolgt.

Wichtig wäre zu schauen, ob der Effekt trotzdem eintritt (bei mir tut er es), nämlich, dass dann bis zum nächsten Schaltzeitpunkt auf Absenkmodus gewechselt wird. Bei mir schlägt sich das auch nicht in Parameter 700 nieder, sondern ist nur an der Therme anhand der Symbole ablesbar.

Gruß,

F.

[acfischer42]

Jo, genau so ist es. Hab's grad getestet.

http://bsb-lan/S1001=0
Setzt auf Praesenzmodus=An (d.h. Komfortschaltung, Sonne am Display)

und

http://bsb-lan/S1001=1
Setzt auf Praesenmodus=Aus (d.h. Reduziert, Mond)

INF Telegramme mit I1001=x haben bei mir nicht funktioniert.
Ausser am Display und im Verhalten der Therme habe ich auch keinen Parameter gefunden der das Anzeigt. 700/1000 bleiben wo sie sind. 900 / 1200 ebenso.

Danke und Gruesse Achim

[freetz]

Ok, dann ist es so wie bei mir und es gibt drei verschiedene Arten, wie die Thermen auf eine Abfrage des Präsenzmodus reagieren (zufällige Werte, immer 0 oder mit Error 7), die aber alle nicht den tatsächlichen Status wiederspiegeln, genausowenig wie sich dieser in den eigentlich dafür zuständigen Parametern 700/1000 etc. finden lässt.

An sich ist die Funktion aber dennoch nützlich, denn wenn ich z.B. für den Rest des Tages aus dem Haus gehe, kann ich damit auf Reduziert schalten, ohne mich darüber zu sorgen, dass es am nächsten Morgen noch kalt ist, wenn ich vergessen sollte, das zurück zu setzen.

Die Frage ist, was passiert, wenn man gleichzeitig Parameter 700 auf Reduziert setzt (damit man eine konsistente Anzeige hätte). Springt dann bei der nächsten Schaltzeit der 700er auf "Komfort" zurück oder bleibt er (dauerhaft?) auf "Reduziert"?
Wäre toll, wenn das mal jemand testen könnte - ich selber nutze die Schaltzeiten gar nicht mehr, sondern steuere das in Abhängigkeit der Raumtemperaturen komplett über FHEM...

Gruß,

F.

[numsi]

@acfischer42
Die Präsenztaste muss aber aktiviert/zugeordnet sein im Bediengerät via Parameter 48.
Sonst kommt ja beim drücken auch ein Hinweis.

Und das Symbol verät nix über die Präsenzfunktion sondern zeigt IMHO nur den
Betriebszustand an.
Hier wechselt das Symbol immer, egal ob via Taste oder Zeitprogramm, ich kann nicht
sehen ob das von der Taste kommt.

[freetz]

Nochmal zum Trinkwasser Push durch 3s drücken der TWW-Taste: Bei meiner Elco Thision S17.1 kommt da die Meldung im Display "Manueller Trinkwasser-Push gesperrt". Im Netz habe ich jetzt gefunden, dass dies mit einem der OEM-Parameter freigeschaltet werden muss. Zumindest bei denen, die wir dekodiert haben, finde ich aber keinen Hinweis darauf, wo das einstellbar sein könnte/müsste. Hat jemand von Euch da eine Idee? Ansonsten müsste das jemand anderes mal ausprobieren und die Telegramme mitschneiden...

EDIT: Gleiches Ergebnis auch bei der Brötje ZR1...

[numsi]

Du hast aber schon mal nachgeschaut als OEM?

[freetz]

Für meine Elco kenne ich den OEM nicht, und die mir bekannten Brötje Codes gehen auch bei der ZR1 nicht...

[numsi]

Dein ZR1 geht mit Sicherheit auf OEM, schau mal in meine Signatur 

[freetz]

Danke - beim ZR1 hat's geklappt, aber da bekomme ich so oder so leider kein Trinkwassermenü angezeigt, und unter "Konfiguration" habe ich keinen Parameter gefunden, der darauf hindeuten könnte... Muss also doch jemand anderes mal schauen...

[freetz]

Im Master Repository hat es durch neue Parameter einen Speicherüberlauf gegeben - das letzte Release (0.39) war davon nicht betroffen, also nur für Leute, die in den letzten zwei Tagen das Master Repository heruntergeladen haben.
Ich habe das jetzt durch die Auslagerung des Konfigurations-HTML-Code in die _defs.h erst einmal abgewendet. Aber für weitere Parameter / ENUM-Texte etc. müsste mir jemand helfen, wie ich die STR- und ENUM-Texte der Parameter von PROGMEM in PROGMEM_LATE bekomme.
Leider kann ich in der cmdtbl statt der Referenz auf STRxxxx kein pgm_get_far_address(STRxxxx) angeben, da der Compiler dann meckert:
"statement-expressions are not allowed outside functions nor in template-argument lists".

Falls jemand von den C-Spezialisten hier einen Tipp hat, wäre das für zukünftige Erweiterungen sehr hilfreich...

Gruß,

F.

[postman]

Moin freetz,

Holgers Platine läuft jedenfalls jetzt wieder in meiner Heizung (mit dem ,,echten" SainSmart), damit ich daran mal sehen kann, ob es da vielleicht auch bei längerer Laufzeit Probleme gibt. Ärgerlich ist das schon, denn wenn es, wie es aussieht, an Streuungen in der Bauteilqualität liegt, und dabei unklar ist, ob die Ursache die Bauteile der Platine (die von reichelt.de sind), die des Arduino oder ein Zusammenspiel beider ist, dann ist es natürlich schwer eine Empfehlung auszusprechen.

Aslo, ich habe die Bauteile auch von dort. Tolleranzen wird es sicherlich geben, allerdings bei den verwendeten Bauteilen des Adapters eher zu vernachlässigen. Für mich sieht das aber eher danach aus, dass die Leistung nicht ausreicht (?), die vom Arduino an den  Adapter weitergegeben wird. Mess mal die Spannung, die am Apter anliegt; sie sollte nicht unter 4,6 V liegen. Alles darüber bis 5 V ist gut; darunter wäre ein Netzteil an der Ladebuchse sinnvoll.
Ich habe diesen Arduino als Tipp von Schotty  https://www.amazon.de/Elegoo-Mikrocontroller-ATmega2560-ATMEGA16U2-Kompatibel/dp/B01MA5BLQI/ref=gbph_tit_s-4_f247_2fc810fc?smid=A1780XYQ9DFQM6&pf_rd_p=416f1658-31aa-4610-b3e7-afdd7bc0f247&pf_rd_s=slot-4&pf_rd_t=701&pf_rd_i=gb_main&pf_rd_m=A3JWKAKR8XB7XF&pf_rd_r=E0K6K30XQM0W3C386ZAH
und diesen Ethernetshield https://www.amazon.de/gp/product/B01D0KELYM/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1gekauft. Beides funktioniert ohne Probleme. Einzig zu viele Abfragen lassen das Web auf dem  Arduino manchmal "hängen". Es rappelte sich aber bisher immer wieder auf.

Gruß Uwe

[freetz]

Hallo Uwe,

an die Spannung hatte ich zu Beginn auch gedacht und werde das auch noch mal überprüfen, aber wenn die Spannung zu gering ist, dürfte der in Reihe geschaltete Raspi, der nur zum Mitlauschen auf dem Bus dranhängt, ja die vom Arduino gesendeten Telegramme ja auch nicht empfangen dürfen. Denn in dem Moment, wo der Arduino es schafft, die Optokoppler zu schalten, ist die Arduino-seitige Spannung ja letztlich egal, weil dann ja nur noch die Spannung auf dem BSB relevant ist.
Von daher war/ist meine Hauptvermutung, dass es sich um Schwankungen bei der Prozessorgeschwindigkeit handelt, denn die Sendefunktion basiert hartcodiert darauf, um mikrosekundengenau die Pins entsprechend der Übertragungsgeschwindigkeit zu schalten. Die (zumindest partiell) bemerkbare Verbesserung, wenn ich den TX-Delay um einige Mikrosekunden erhöht/verringert habe, könnte auch ein Indiz dafür sein. Anders kann ich mir nicht erklären, warum die Telegramme auf dem Bus landen, aber von der (möglicherweise sehr pingeligen) Therme nicht als solche erkannt werden.

Aber ich schaue noch mal auf die Spannungen im TX-Pfad, um ganz sicher zu gehen.

Dass der Arduino temporär hängt ist bei parallelen Anfragen normal, da er nur eine Anfrage zur Zeit bearbeiten kann (dazu gehören auch die mehrfachen Parameter in einer URL, da diese nacheinander abgearbeitet werden). Wenn ich aber /K11 abrufe und dann abbreche bzw. parallel z.B. /K37 abrufe, wird zuerst der erste Abruf komplett abgearbeitet (selbst wenn das Browserfenster geschlossen wird) und dann der darauf folgende (usw.).

Einen dauerhaften Absturz, bei dem der Arduino nur noch auf ein Ping reagiert, hatte ich auch nach mehreren Wochen Dauerbetrieb mit Abfragen alle 30 Sekunden und Logging mehrerer Parameter bisher noch nicht.

Danke und Gruß,

F.

[postman]

Hallo freetz,

Von daher war/ist meine Hauptvermutung, dass es sich um Schwankungen bei der Prozessorgeschwindigkeit handelt

Das kann ich mir irgendwie nicht vorstellen, da sowohl der Arduino als auch das Ethernetshield eine extakte Taktsteuerung besitzen (quartz etc.). Da müssten die Schwankungen bereits bei der Generierung des Taktes entstehen, was natürlich nicht ausgeschlossen ist. Das würde aber auch bedeuten, dass die verbauten Quartze entweder defekt, von so schlechter Qualität oder uralt sind, das dadurch Schwankungen auftreten. Da lässt sich dann der entsprechende Arduino nicht verwenden. Hier mal die Daten für den Mega:

Microcontroller    ATmega2560
Operating Voltage    5V
Input Voltage (recommended)    7-12V
Input Voltage (limit)    6-20V
Digital I/O Pins    54 (of which 15 provide PWM output)
Analog Input Pins    16
DC Current per I/O Pin    20 mA
DC Current for 3.3V Pin    50 mA
Flash Memory    256 KB of which 8 KB used by bootloader
SRAM    8 KB
EEPROM    4 KB
Clock Speed    16 MHz
LED_BUILTIN    13
Length    101.52 mm
Width    53.3 mm
Weight    37 g

Vieleicht helfen  Dir die Daten bei der Lokalisierung des Fehlers.
Mehr kann ich Dir da leider nicht weiterhelfen.
Gruß Uwe

[freetz]

Hallo Uwe,

die Specs für die Mega-Varianten wird immer gleich sein. Es würde schon "reichen", wenn die Quartze eben nicht genau die spezifizierte Geschwindigkeit bringen, sondern z.B. statt der exakten 16 MHz "nur" 15,9 oder 16,1 MHz. Für 99% der Anwendungen wird das keinen Unterschied machen, nur eben für solche, die sich genau darauf verlassen, wie lange ein Takt des Prozessors ist. Und dazu gehört eben die SoftwareSerial-Bibliothek, die (angeblich) für jede Übertragungsgeschwindigkeit einzeln ausgemessene Taktdauern für die drei Standard-Taktungen (8, 16 und 20 MHz) hinterlegt hat. Wenn der Raspi dann beim Empfang toleranter mit Geschwindigkeitsabweichungen ist, als die Therme, würde das zumindest erklären, warum der Pi die Telegramme sieht, aber die Therme nicht darauf reagiert.
Aber ich werde noch mal mein Schaltnetzteil ausgraben und den China-Clone daran anschließen. Wenn das dann zu einer Veränderung führt, wäre das ja die beste aller Erklärungen ...

Gruß,

F.