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

[freetz]

Sorry, mit den Details des ESP und der AT-Firmware kenne ich mich nicht aus, die sollte sich aber bei Espressif finden lassen. Für das Thema hier wird das aber dann zu sehr off-topic; falls es am Ende aber nicht nur an den lokalen Begebenheiten und/oder einem defekten ESP liegt, kannst Du natürlich gerne die Lösung hier berichten!

[Schotty]

@Bratmaxe: Vielleicht kann dir sonst jemand im entspr Unterforum https://forum.fhem.de/index.php/board,74.0.html helfen..?

[loetmeister]

Hi freetz,

sehe das einige neue commits dazu gekommen sind...
Ich habe mal ein "Merge" gemacht und ein wenig 'aufgeräumt'... Dabei ist mir aufgefallen, dass char version[] dynamischen Speicher belegt, auch wann sie als static const definiert... const byte exclude_GPIO[] landet aber nicht im RAM... beides nutzt client.print(). Also eigentlich vergleichbar....
https://github.com/fredlcore/bsb_lan/compare/master...loetmeister:master#diff-3b1acad954dc4894468541ff5486ddf5L175

Habs mal mit print "F" makro erstellt... dann ist es logischer weise nicht mehr im RAM...
https://github.com/loetmeister/bsb_lan/commit/43774c60b79330f7d5b54c4150b1970553c919f3

Gruß,
Thomas

[freetz]

Danke für die Mühen! Aber bitte sieh's mir nach, dass ich bei der Menge an Änderungen einige Zeit brauche, das nachzuvollziehen und da, wo es dann passt, zu übernehmen. Da ich den Code durch die letzten Jahre ziemlich gut "im Kopf" habe, ist ein einfaches Komplett-Mergen leider (für mich) nicht so sinnvoll.
Ich habe gesehen, dass Du bei OneWire einiges geändert/geupdated hast, was hat das für einen Grund? Einfach nur einer neueren Version wegen oder gab es irgendwo Probleme?

[loetmeister]

ok.. kein Problem.
OneWire.. ja, hatte ich vergessen zu erwähnen... ist einfach nur die aktuelle Version. Keine weiteren Änderungen. Spart auch Speicher... scheint als gabs da ein paar Optimierungen.
Könntest du auch ganz aus dem BSB LAN repository raus nehmen, dann muss die jeder in Arduino hinzufügen... und aktuell halten.

Gruß,
Thomas

[freetz]

So, hab' jetzt versucht alles mal zu überfliegen und das macht natürlich alles Sinn - ich überlege jetzt, ob man irgendwie sinnvoll verhindern kann, dass alle Leute, die Updaten beim Kompilieren eine Fehlermeldung bekommen, weil sie vormals bus_type und nicht wie jetzt BUS_TYPE in der _config.h definiert haben. Wenn man jetzt von der (natürlich passenderen) Nomenklatur abweicht und bus_type weiterhin klein schreibt, könnte man aus Kompatibilitätsgründen hier einfach noch den übergebene Wert zurück liefern. Dann hätte man die User, die nur flashen können/wollen mit an Bord und trotzdem die Vorteile Deiner Lösung, oder? Wie gesagt, irgendwann, wenn die Konfiguration komplett über das Webinterface gemacht werden kann, müssen die ganzen Variablendefinitionen eh' aus der Config rausfliegen oder angepasst werden, aber das würde ich dann gerne dann machen, wenn eh' ein größerer Wechsel ansteht...

[Schotty]

Könntest du auch ganz aus dem BSB LAN repository raus nehmen, dann muss die jeder in Arduino hinzufügen... und aktuell halten.

..da würde ich ein Veto einlegen wollen - das wird früher oder später zu Problemen & vermehrten Nachfragen führen. Auch wenn ich es dann natürlich im Handbuch erwähnen würde, aber das wird -zumindest gefühlt- auch nicht immer sooo aufmerksam gelesen..
Nachtrag: ..und wird die Sache gerade für Einsteiger eher komplizierter als einfacher machen, weil sie noch mehr zu beachten haben..

[freetz]

Nein, das mit den Libraries im Unterverzeichnis von BSB_lan ist natürlich nicht die reine Lehre, aber es verhindert auch, dass Versionsupdates zu Brüchen führen, die dann aus der Ferne nur schwer zu supporten sind ("Kompilieren klappt nicht mehr" mit angehängtem Screenshot einer Minisequenz der Konsolenausgabe ) - man darf nicht vergessen, dass der BSB-LAN-User zum ersten Mal mit Code zu tun haben. Ab und an aktualisiere ich auch die zentralen Libraries, nur halt nicht so prioritär bei denen, die schon seit fast einem Jahrzehnt treu ihren Dienst tun ...

[loetmeister]

So, hab' jetzt versucht alles mal zu überfliegen und das macht natürlich alles Sinn - ich überlege jetzt, ob man irgendwie sinnvoll verhindern kann, dass alle Leute, die Updaten beim Kompilieren eine Fehlermeldung bekommen, weil sie vormals bus_type und nicht wie jetzt BUS_TYPE in der _config.h definiert haben. Wenn man jetzt von der (natürlich passenderen) Nomenklatur abweicht und bus_type weiterhin klein schreibt, könnte man aus Kompatibilitätsgründen hier einfach noch den übergebene Wert zurück liefern. Dann hätte man die User, die nur flashen können/wollen mit an Bord und trotzdem die Vorteile Deiner Lösung, oder? Wie gesagt, irgendwann, wenn die Konfiguration komplett über das Webinterface gemacht werden kann, müssen die ganzen Variablendefinitionen eh' aus der Config rausfliegen oder angepasst werden, aber das würde ich dann gerne dann machen, wenn eh' ein größerer Wechsel ansteht...

Hm.. Ja, bus_type könnte man auch schreiben, aber der Funktions Aufruf müsste da weg..
bus.setBusType(0) darf erst in setup() kommen.

Gruß,
Thomas

[freetz]

Hm, ich hab's jetzt mal so geändert und in meiner _config.h steht noch

Code Auswählen Erweitern

uint8_t bus_type = bus.setBusType(0);
und das kompiliert er auch ohne Murren, wenn ich als letzte Zeile in der setBusType ein

Code Auswählen Erweitern

return bus_type_val;
anhänge.
Eigentlich würde er doch bei einer "alten" config dann nur eine globale Variable bus_type erstellen, die dann halt ein Byte mehr verbrauchen würde, oder wo soll sonst das Problem liegen?

EDIT: PS: Könntest Du aus Deinem zweiten Link mit den Byte Savern auch noch einen Pull-Request generieren? Die würde ich auch gerne übernehmen...

[freetz]

An alle User, die den Gesamtertrag Solarenergie an Ihrer Therme abrufen können: Könntet Ihr bitte mal schauen, ob der angezeigte Wert bei Parameter 8527 zwischen Therme und BSB-LAN übereinstimmt? Mich hat ein User nun darauf hingewiesen, dass bei ihm der Wert in BSB-LAN nur ein Zehntel dessen ist, was an der Therme angezeigt wird (also nur 100 statt 1000 kWh). Da dieser Parameter schon vor meiner Zeit hinterlegt war, habe ich keine Logs anhand derer ich das prüfen könnte...

[DeejayT]

Hallo in die Runde!
Folgendes Problem, wenn ich mir per

Code Auswählen Erweitern


http://192.168.1.36/JQ=2200,2201,2203,2204,2205,2206,2210,2211,2212,2213,2214,2215,2220,2221,2222,2232,2233,2234,2235,2236,2237,2238,2240,2241,2243,2245

die Werte auslesen lasse, dann bekomme ich für den Parameter 2215 für den Value=decoding error

Eine weitere Frage: Mir kommt es so vor, als wenn einige Parameter nicht zur Verfügung stehen, die ich sonst am Bediengerät auslesen kann.
Wie zum Beispiel die Drehzahl der Kesselpumpe. Da steht im BSB-LAN Interface "parameter not supported"

[Schotty]

Bzgl 'decoding error' siehe https://1coderookie.github.io/BSB-LPB-LAN/kap13.html#135-fehlermeldung-decoding-error
Bzgl etwaiger Parameter, die via kesselseitiger Bedieneinheit verfügbar sind, via BSB-LAN jedoch nicht, siehe https://1coderookie.github.io/BSB-LPB-LAN/kap10.html - da dann Dekodieren gemäß Kap. 10.1

[loetmeister]

EDIT: PS: Könntest Du aus Deinem zweiten Link mit den Byte Savern auch noch einen Pull-Request generieren? Die würde ich auch gerne übernehmen...

Oh man.... ich hab grad einen neuen branch angelegt und mit "cherry-pick" versucht dir den letzten commit von dem neuen branch per pull-request zu schicken... "cherry-pick" hat aber immer gesagt "The previous cherry-pick is now empty"... bis ich dann festgestellt habe das du die Änderungen bereits in deinem repository integriert hast.   

Damit sind die Änderungen an z.B. "BSB_lan_config.h.default" mit drin. War das so beabsichtigt?

EDIT: Sehe grad das es noch weitere Vorkommen von "pint version" gab, hatte ich übersehen... https://github.com/fredlcore/bsb_lan/commit/f98d43e4d6a36a56e40fe7ed508d17a865802e88#diff-1118998d47d0c636c492e49a080339afR5177
Wenn du dort auch das "F" Makro nutzt (print(F(BSB_VERSION))) sparst du noch mehr RAM: -22 byte RAM +24 byte flash

bzgl. uint8_t bus_type = bus.setBusType(0);, jetzt habe ich verstanden warum du wieder einen wert aus der Funktion bekommen wolltest... das klappt so, kostet 38 byte flash + 1 byte RAM, im vergleich zu constexpr uint8_t bus_type = 0;. 10 weitere byte im flash wenn die Funktion wieder "void" ist... denke das ist verkraftbar.

PS: @Schotty, das mit den weiteren libs (z.B. OneWire) aus dem BSB LAN repository raus nehmen war nicht so ganz ernst gemeint... so ist es einfacher, auch wenn man dann hin und wieder manuell aktualisieren muss...

Gruß,
Thomas

[freetz]

Danke für den Tipp mit F(BSB_VERSION), führe ich noch nach - aber die Änderungen die Du in Deinem Byte Saver Link hattest, sind noch nicht mit dabei gewesen, daher die Bitte, ob Du damit noch mal einen PR machen kannst?