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

[Maista]

@freetz

Ich hab Urlaub und mal Zeit, tschuldigung 

Keine Ahnung, ich dachte du willst mir Grundsätzlich JSON schmackhaft machen und alles damit erledigen?
Ich habe nur die paar Attribute eingetragen. Als Ahnungsloser bin ich selbst erstaunt das es so einfach geht
Über das SET kann kann in der Dropdown sein Parameter auswählen und abschicken.
Das geht , wie über HTML, auch für weitere Parameter.

Man muss nur für die gewünschten Parameter die Zeilen anpassen, und durchnummerieren.

Code Auswählen Erweitern

attr LMS14_1 set01Data {"Parameter":"700", "Value":"$val", "Type":"1"}
attr LMS14_1 set01IMap 0:Schutzbetrieb, 1:Automatik, 2:Reduziert, 3:Komfort
attr LMS14_1 set01Name Betriebsart

Ob nun HTML oder per JSON besser ist kann ich nicht beurteilen.
Es funktioniert.
Bei JSON dürften aber weniger Daten zu übertragen sein als per HTML-Seite?

Ob Schotty mein Beispiel mit in die Doku übernimmt bleibt Euch überlassen.

Gruss Gerd

[freetz]

Jeder kann natürlich die Methode verwenden, die ihm am besten erscheint. Vorher ging es aber um das Auslesen von Parametern und der richtigen Konfiguration von RegEx, das ist bei set Befehlen nicht relevant.
Wenn man JSON für das Setzen verwendet, sind es bei Dir vier Attribute, die gesetzt werden müssen, und mit Date und URL auch noch solche, die deutlich komplexer und in der Eingabe fehleranfälliger sind, als wenn man über /S geht. Da reichen im Minimalfall zwei Attribute aus:

Code Auswählen Erweitern

set0Name Komfortsollwert
set0URL http://192.168.178.88/S710=$val
Für ENUMs dann halt noch ein Mapping, wenn nötig, aber das war's. Es gibt sicher viele Wege, die nach Rom fahren, aber dieser hier entspricht am ehesten dem, wie man auch über das Webinterface Parameter setzen würde, so dass die Leute am wenigsten "umlernen" müssen. Von daher sollte das im Handbuch die Lösung sein, die wir empfehlen.

[Luposoft]

Hallo Leute,

ich hab mir das mit dem JSON mal angeschaut.
Dazu habe ich ein neues HTTPMOD angelegt mit ein paar Parametern.
Mit Interval>0 klappt das.
Wenn ich nun manuell abfragen will, also Interval=0


mein Versuch : get <HTTPMOD> <Klartextname> bringt die Fehlermeldung 'unknown argument <Klartextname>

wie ist da die Syntax?

[freetz]

Es gibt analog zu reading01JSON auch noch get01JSON, dazu am besten mal in der CommandRef nachschauen; ich hatte bei den ersten Versuchen damit aber immer wieder Meldungen wie "Read response to update didn't match any Reading" in der Logdatei, kann aber mit dem Intervall, das ich dann hatte, zusammenhängen. Wenn Du eine laufende Konfiguration hast, dann gerne hier posten.

[loetmeister]

Hallo,

mal ne Frage... die wahrscheinlich nicht zum ersten mal gestellt wurde... Laut BSB_lan_config.h und Handbuch https://1coderookie.github.io/BSB-LPB-LAN/kap05.html muss ich mir selber die Parameter raussuchen, die ich Schreibbar haben möchte. Es gibt keine vordefinierte Liste an "sicheren" Parametern, welche ich schreibbar machen kann (ähnlich wie die als "OEM" markierten Parameter) - richtig?
(das hängt ja vermutlich alles von meiner Heizung ab, Hersteller, Modell, etc.)

@freetz

Dann werde ich im neuen Layout den 560k auch im RX-Pfad vorsehen. 470k würde zu einer schnelleren Entladung führen, oder? Was hätte das für einen Vorteil? Und hast Du den 10k-Pulldown nur der Vollständigkeit der Abweichungen von Maista halber aufgeführt oder wirkt sich das auch noch aus, ob da 4k7 oder 10k Pulldowns verwendet werden?

Ja, hatte es der Vollständigkeit halber erwähnt... und auch weil ich mehr 470k als 560k in der Bastelkiste habe

Gruß,
Thomas

[Schotty]

Hi Thomas,
genau, vordefinierte Listen 'sicherer' Parameter gibt es bei uns nicht. Du kannst entweder prinzipiellen Schreibzugriff erlauben (default flag 0) oder eben einzelne Parameter als schreibbar in der defs.h definieren. Bei der letzteren Variante wirst du aber vermutlich alles neu einstellen müssen, sobald du eine neuere/aktualisierte Version der defs.h aus dem Repo herunterlädst und flashst (korrekt? @freetz).

[freetz]

Ja, "sichere" Parameter gibt es nicht, weil sich sogar die OEM-Parameter von Hersteller zu Hersteller unterscheiden. Bei meiner Thision ist eine ganze Menge an Parametern nur auf der OEM-Ebene erreichbar, die bei anderen frei erreichbar sind. Ich habe daher alle, von denen ich weiß, dass sie OEM sind, so geflaggt, sicher ist sicher. Bei denen, wo ein Schreiben keinen Sinn macht, habe ich diese generell auf read-only gesetzt. Alle anderen sind über DEFAULT_FLAG erst einmal ebenfalls read-only. Ich überlege mir mal, ob ich für das Setzen der Raumtemperatur und des Betriebsmodus eine eigene "Kategorie" einführe, damit man diese dann selektiv über die Config dann schreibbar schalten kann, wenn man das nur für diese braucht.

[Schotty]

DAS wäre natürlich eine richtig feine Sache! Dann auch so Geschichten wie TWW-Push etc - klasse

[freetz]

Dann sammelt doch bitte mal die Parameter, die für so eine "harmlose" Nutzung schreibbar sein sollten, dann baue ich das so ein...

[Luposoft]

Ich wünsche dem gesamten Forumsmitgliedern ein gesundes Neues Jahr!

@freetz - zur Wunschliste sichere Parameter

ich schalte:
700 - Betriebsart HK1
1601- TWW Push
5890 - Relais QX1

Nach einem update muss ich immer höllisch aufpassen, diese Einträge nicht zu vergessen, wäre toll wenn da was machbar ist.

---------------------------------------------------------------------------------------
Ich hab mich mit dem JSON beschäftigt
und letztendlich auch hinbekommen...
Hier mein Beispiel

Code Auswählen Erweitern


defmod TEST1 HTTPMOD http://192.168.68.39/JQ=8326 300
attr TEST1 userattr get01JSON get01Name get01URL reading03JSON reading03Name
attr TEST1 get01JSON 700_value
attr TEST1 get01Name Betriebsart
attr TEST1 get01URL http://192.168.68.39/JQ=700
attr TEST1 reading03JSON 8326_value
attr TEST1 reading03Name Modulation
attr TEST1 showError 1


mit 'get TEST1 Betriebsart' wird manuell die Aktualisierung von Parameter 700 angestoßen. Der neue Wert steht dann im Reading.
Der Parameter 8326 wird periodisch automatisch geholt, im Beispiel alle 300s.

Eine Frage zum periodischem abholen...
Sehe ich richtig, dass MQTT dafür der Vorzug zu geben ist?

[Luposoft]

Ach eine andere Frage hab ich noch.
Um nicht immer im Keller zu sitzen, wenn ich am Arduino programmiere/update, möchte ich mir was anderes einfallen lassen.
Meine erste Idee: Einen Remoteserver mit dem Arduino via USB verbinden, und auf den dann via Remotedesktop zugreifen.

Hat jemand von euch eine bessere Lösung im Kopf bzw. realisiert?

[freetz]

Mein Arduino hängt an einer NAS, die im Keller steht, dort habe ich minicom und avrdude installiert, so dass ich von der Ferne aus den seriellen Monitor einsehen kann als auch ein Firmware-Update durchführen kann.

[freetz]

Eine Frage an die C-Kundigen:
Bei der Portierung des Codes für den Arduino Due habe ich mir gerade mehrere Stunden die Haare gerauft, weil der Code auf dem Due einfach ohne irgendeine Meldung auf der seriellen Konsole hing, und zwar ziemlich direkt von Anfang an.
Schritt für Schritt habe ich herausgefunden, dass der Aufruf der Funktion setBusType gleich aus der _config.h heraus die Ursache war, und zwar ab dem Punkt, wo das erste mal eine Ausgabe über Serial.print() erfolgt, wenn die eigene und die Zieladresse ausgegeben werden. Zuerst dachte ich, dass der Due anspruchsvoller ist und ein Serial.begin() erwartet, das zum Zeitpunkt des Aufrufs aus der _config.h heraus aber noch nicht erfolgt ist und erst in setup() kommt. Aber auch das hat nichts gebracht. Erst nachdem ich die Ausgabe auskommentiert habe, lief der Coder weiter bis zur setup()-Funktion und hat da dann auch keine Probleme mit dem Ausführen von Serial.print-Aufrufen.

Ich stehe jetzt vor zwei Fragen, zum einen: Warum ist der Aufruf von Serial.print() aus einer Funktion vor der eigentlichen setup()-Funktion beim Arduino Due im Gegensatz zum Uno/Mega ein Grund für einen Hänger/Absturz, selbst wenn davor noch ein Serial.begin() gesetzt wird?
Und zum anderen: Wie kann ich in der Funktion erkennen, ob die setup()-Funktion bereits durchlaufen ist und ich somit aus den Funktionen heraus auf die serielle Schnittstelle zugreifen kann?

Freue mch über jeden Hinweis!

[loetmeister]

Hi,

Ich stehe jetzt vor zwei Fragen, zum einen: Warum ist der Aufruf von Serial.print() aus einer Funktion vor der eigentlichen setup()-Funktion beim Arduino Due im Gegensatz zum Uno/Mega ein Grund für einen Hänger/Absturz, selbst wenn davor noch ein Serial.begin() gesetzt wird?
Und zum anderen: Wie kann ich in der Funktion erkennen, ob die setup()-Funktion bereits durchlaufen ist und ich somit aus den Funktionen heraus auf die serielle Schnittstelle zugreifen kann?

Nutzt der ARM Cortex des Due den AVR GCC? Oder kommt da ein andere Compiler zum Einsatz? Vermutlich ist da einiges anders, ich würde da nicht zu sehr Suchen, mich statt dessen darauf fokussieren alles in setup() und loop() zu haben. Wenn das ordentlich ist, dann brauchst du dir über Serial.begin() keine Sorgen machen, da alles was Serial.print() nutzt danach kommt, bzw. in loop() ausgeführt wird.

Ich hatte ja eine mögliche Option umgesetzt, setBusType() in setup() zu verschieben... das bedingt die BSB_lan_config.h zu ändern.
https://github.com/loetmeister/bsb_lan/blob/5c817554f8167a4af9b470f0916ac975be82f6b5/BSB_lan.ino#L6729

Gruß,
Thomas

[freetz]

Ja, das Verschieben in den eigentlichen Code ist eine Option, aber dann müssen alle, die updaten, das entsprechend ändern und da sehe ich dann die Fragen kommen (ggf. direkt per Mail an mich, weil die Leute nicht alle im Forum sind), so dass ich das gerne vermeiden möchte (abgesehen davon, dass ich ja auch gerne etwas daraus lernen würde, was da das Problem ist). Als Compiler kommt der arm-none-eabi-gcc zum Einsatz.