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

[Schotty]

@Jens: Bitte sag Bescheid, wenn du die Lösung gefunden hast - wenn es wirklich an der 0 liegen sollte, dann muss ich das natürlich auch im Handbuch ändern.. Danke

[Jewe]

Hallo Gerd,

ich habe meine HTTPMOD Devices umgeschrieben und mit reading1Regex als erstes angefangen. Nun funktioniert wieder alles. Ich weis un nicht, welche Änderung das verursacht hat, denke aber es liegt am HTTPMOD-Modul.

@Schotty, Du kannst das Handbuch entsprechend anpassen. Ohne "reading0Regex" funktiniert es wieder.

@Freetz, Schotty, wird es in den zukünfigen Versionen weiterhin JSOn und MQTT2 geben ?

Danke, Jens

[Maista]

Moin Jens

Ja das hat mich auch Zeit gekostet.
Manche Dinge könnten so einfach sein 

Schön dass es nun klappt.

Gruß Gerd

[freetz]

Ok, ich kann das jetzt auch bestätigen. @Schotty: Bitte im Handbuch dann bei readingXName und readingXRegex mit 1 anstatt mit 0 anfangen...

[Schotty]

Komisch, in dem Thread meint dieter114 allerdings, dass das bei ihm wohl nur BSB-LAN betreffen würde..?! Gibt's dafür eine mögliche Erklärung?

@freetz: Ich habe jetzt bei allen `readingXName` und `readingXRegex` jeweils um 1 erhöht. Zusätzlich auch bei `setXName` und `setXURL`, da das doch sonst auch nicht mehr gepasst hätte - war das so richtig? Bitte sieht dir nochmal ganz genau die Beispiele an, damit da jetzt auch alles i.O. ist..
https://1coderookie.github.io/BSB-LPB-LAN/kap11.html#1112-einbindung-mittels-httpmod-modul
Wenn du grünes Licht gibst, dann ändere ich es entsprechend auch in der englischen Version.

@Jewe: Du meinst in zukünftigen BSB-LAN-Versionen? Ich wüsste nicht, was dagegen sprechen sollte. Also ja, du kannst JSON oder MQTT(2) ruhig benutzen

[freetz]

Ich meine gelesen zu haben, dass reading0... schon seit einiger Zeit nicht mehr offiziell unterstützt wird und nun rausgefallen ist.
set0... ist davon nicht betroffen, gerade noch mal ausprobiert. Trotzdem macht es vermutlich Sinn, dass man auch dort mit 1 anfängt, damit es einheitlich aussieht.
EDIT: Im zweiten Beispiel hast Du's ja schon geändert, im ersten noch nicht...

@Jewe: Die Funktionen, die jetzt implementiert sind, werden auch im Due verfügbar sein. Nur werden dann, wenn der Speicher beim Mega voll ist, dort keine neuen Funktionen mehr hinzu kommen.

[Schotty]

@freetz: Ah ja, danke fürs Checken, dann ändere ich das auch so bei der englischen Version.

[dieter114]

Komisch, in dem Thread meint dieter114 allerdings, dass das bei ihm wohl nur BSB-LAN betreffen würde..?! Gibt's dafür eine mögliche Erklärung?

Hallo Schotty
genauso ist es, und das verstehe ich nicht.
Dort wird eindeutig mit reading0Regex begonnen und es läuft einwandfrei. 
Übrigens wenn man ein neues HTTPMOD anlegt wird als Attr auch das reading0Regex angeboten,
also muss das wohl schon (noch) gehen - oder???

Edit: Habe wie Jewe alles umgeschrieben und es läuft wieder.

Grüße Wolfdieter

[freetz]

So, inzwischen hat GitHub user dukess eine sehr interessante Idee, um beim Mega Speicherplatz zu sparen (da er auch die russische Sprachversion pflegt, kommt es hier wegen des höheren Speicherplatzbedarfs von Unicode-Zeichen schon jetzt zu übervollem Speicher), indem Sprachdateien und Webseiten auf SD-Karte ausgelagert werden. Das Ganze erfordert dann zwar initial das Hinüberkopieren von bestimmten Dateien auf die SD-Karte, aber könnte noch ein bisschen mehr Luft verschaffen und darüber hinaus auch noch andere Möglichkeiten bieten (moderneres Design, AJAX etc.).
An der Weiterentwicklung auf/für den Due wird das wohl nichts ändern, aber ich habe jetzt einmal mit der Version 0.43 einen Schnitt gemacht, bevor dukess dann seine Änderungen einpflegen kann. Es ist nicht geplant, hier für den Mega noch einmal eine grundsätzliche Änderung herbeizuführen, sondern dass seine Änderungen optional sind. Dennoch kann es sein, dass durch einigen neuen Code das System nicht gleich die Stabilität der letzten Wochen und Monate vorweisen kann. Daher hier noch einmal die Zusammenfassung der Version 0.43, wie sie jetzt released ist:

Code Auswählen Erweitern



    Added support for HardwareSerial (Serial1) connection of the adapter. Use RX pin 19 in bus() definition to activate. See manual/forum for hardware details.
    Added definement DebugTelnet to divert serial output to telnet client (port 23, no password) in BSB_lan_config.h
    Added possibility to control BSB-LAN (almost?) completely via USB-serial port. Most commands supported like their URL-counterparts, i.e. //xxx to query parameter xxx or //N to restart Arduino.
    Changed default device ID from 6 (room controller "RGT1") to unused ID 66 ("LAN")
    Many new parameters, please run /Q to see any possible changes for your device family and report back to us!
    Added global variables (arrays of 20 bytes) custom_floats[] and custom_longs[] for use with BSB_lan_custom.h, for example to read sensors etc. Output of these variables is done via new URL command /U
    Added device families 23 and 29 (Grünenwald heaters)
    Added device families 49, 52, 59 (Weishaupt heaters)
    Added device fmilies 91, 92, 94, 118, 133, 136, 137, 165, 184, 188 (various controllers like QAA75 or AVS37)
    Added device family 171 (Bösch wood pellet system)
    Added device family 172 (SensoTherm BLW Split B (RVS21.826F/200))
    Added device families 186 and 164 (Olymp WHS-500)
    Added device family 195 variant 2 (Thision 19 Plus / LMS14.111B109)
    Including DHT, 1Wire and burner status parameters (>20000) to MQTT
    English is now default language
    Updated various translations
    Added STL files to print a case with a 3D printer (thanks to FHEM user EPo!)
    Moved all sensors to /T , /H is now no longer used
    New virtual parameters 702/703 for Weishaupt room controller
    New virtual parameter 10003 to set outside temperature on newer systems
    Added text descriptions for error phases (6706 ff.)
    /Q is now more comprehensive
    New data types VT_CUSTOM_ENUM and VT_CUSTOM_BYTE to extract information from non-standard telegrams (such as 702/703)
    Bugfix: DHCP (ethernet) implementation


Version 0.44 wird sich dann vorranging mit seinen Änderungen befassen, und wenn die Due-Anbindung finalisiert ist, springen wir dann auf die Version 1.0 ...

[Schotty]

Über eine solche Möglichkeit hatten wir aber doch auch schon mal gesprochen, da fandest du es aber nicht gut/praktikabel - wo/was ist jetzt der Unterschied zu dukess' Vorschlag?
Verstehe ich das richtig, dass somit also die 'letzte/finale' Mega-Version die uneingeschränkt zu empfehlen ist die v0.43er ist und die v0.44er dann eher als 'Testversion' zu verstehen ist? Dann müssten/sollten wir das entsprechend im Handbuch und auch bei GitHub sehr deutlich machen, ebenso dann überall auf das v0.43er-Repo verlinken und nicht mehr auf das jeweils aktuelle zip im BSB-LAN-Repo..?! 

[freetz]

@Schotty: Tut mir leid, ich weiß nicht mehr genau, wann wir wie darüber gesprochen hatten, und ich selber hätte diese Änderungen auch nicht programmieren wollen. Er hat das nun getan, und über AJAX lassen sich dann auch noch ganz andere Dinge umsetzen (die auch ich nicht umsetzen werde, sondern andere, wenn ihnen danach ist). Da es in der Form der Umsetzung aber den Rest nicht stören sollte und es eben für die Unicode-Sprachen eine Möglichkeit gäbe, das System jetzt überhaupt nutzen zu können, habe ich die bereits gemachte Arbeit natürlich nicht abgelehnt. Es wird aber auch damit weiterhin Einschränkungen geben, weswegen ein Wechsel auf den Due letztlich auf längere Sicht sinnvoller ist, aber wie gesagt, wer mit dem System jetzt zufrieden ist, kann darüber vielleicht noch etwas länger mit neuen Funktionen auch auf dem Mega rechnen.

Und nein, das wird wahrscheinlich nicht die letzte Version für den Mega sein (s.o.), nur sind neue Versionen aus dem Master-Branch natürlich immer mit etwas Vorsicht zu genießen, das war aber schon immer so. Auf der anderen Seite gibt es natürlich auch keine Garantie, dass eine Release fehlerfrei ist, nur in dem Fall stehen halt jetzt ein paar mehr Änderungen an, die natürlich auch eventuell fehlerträchtiger sind. Aber wie gesagt, das war schon immer so, insofern kein Grund für irgendwelche Änderungen.

[Schotty]

Das Thema hatten wir privat und auch hier im Forum, aber darum geht's mir nicht (also nicht falsch verstehen, ist keine 'verletzte Eitelkeit' oder sowas ).
Bei mir schrill(t)en nur eben etwas die Alarmglocken, als ich diese Zeilen las:

Dennoch kann es sein, dass durch einigen neuen Code das System nicht gleich die Stabilität der letzten Wochen und Monate vorweisen kann.
...
Version 0.44 wird sich dann vorranging mit seinen Änderungen befassen, und wenn die Due-Anbindung finalisiert ist, springen wir dann auf die Version 1.0 ...

Insofern war mein Gedanke gerade, ob es dann nicht evtl sogar sinnvoller wäre, wenn du dafür ein extra Repo anlegst, wo es 'rein' um diejenige Version geht?
1.) Kannst du ja bei der v0.43er bspw keine /Q-Parameter nachträglich mehr freigeben (wenn man die jetzt mal als vorerst letzte 'stabile' Version ansieht) und
2.) bedarf es bei dukess' Version dann ja sicherlich nochmal anderer Einstellungen in der Konfig etc, die dann nur für einige wenige User in Frage kämen und die ich dementsprechend auch besser im Handbuch (nämlich als extra Kapitel) deutlich machen könnte, eben mit Verweis auf das dann zu nutzende Repo. Wenn du für Änderungen diesbzgl dann ohnehin nicht 'zuständig' bist, wäre es vielleicht auch für Euch praktikabler, die Version zu pflegen.
Sollte es also wirklich instabiler werden (können), dann befürchte ich gerade ein wenig 'Kuddelmuddel' und etwaige auftretende Probleme in Zukunft, denn ich kann mir vorstellen, dass viele auch weiterhin den Mega nutzen werden. Insofern wäre (zumindest für die erste 'Testphase') ein eigenständiges Repo vielleicht besser, was ja final -wenn alles läuft- dann trotzdem in die reguläre Mega-Version gemerged werden kann - oder?
 

[freetz]

Wie gesagt, das, was ich geschrieben habe, trifft im Prinzip auf jede Änderung zu. Nur weil es jetzt eben an mehreren Stellen Änderungen geben wird, ist das Risiko theoretisch etwas größer. Aber im Verhältnis zu den Änderungen, die ich jetzt für den Due gemacht habe, bzw. damals die Neuausrichtung der Speicherbelegung etc., ist das immer noch vergleichsweise gering. Dafür ein eigenes Repository aufzumachen, ist, wie wenn man mit Kanonen auf Spatzen schießen würde - von der für mich doppelten Arbeit einmal ganz abgesehen. Insofern vertrau' einfach mal darauf, dass ich schon weiß, wie ich das handhabe ...

[Schotty]

Insofern vertrau' einfach mal darauf, dass ich schon weiß, wie ich das handhabe ...

Das mache ich prinzipiell immer wie du wissen müsstest, aber trotzdem sind ja Nachfragen und Anregungen manchmal auch nicht schlecht..

[loetmeister]

Hi,

Am besten einen branch in github anlegen... Dann kann an der neuen Version unabhängig gearbeitet werden,aber man kann in der aktuellen Version neue Parameter hinzufügen und dies auch zwischen den branches synchron halten.

Gruß,
Thomas