wunschliste modul BSB-Bus (Brötje, Elco Thision etc.)

Begonnen von justme1968, 14 Februar 2018, 14:09:54

Vorheriges Thema - Nächstes Thema

freetz

Die HTML-Classes kann ich gerne so einbauen, kein Problem. Am besten schickst Du mir eine HTML-Seite, wo Du die Classes so eingetragen hast, wie Du sie brauchst, das erspart mir (wie jetzt beim JSON-Hash), dass ich die Sache im Zweifelsfall noch mal anpassen muss. Auch für die JSON-Struktur schicke mir bitte ein Muster für das, was Du senden und empfangen willst, dann weiß ich sicher, wie Du das meinst.

Die Einheiten kann ich übrigens doch auch als ENUM-Wert angeben, nur kann es da (selten) vorkommen, dass sich die Reihenfolge da ändert, weil ich die in dem ENUM nach Einheit gruppiert habe; d.h., wenn es z.B. einen neuen Divisor für "Sekunden" gibt (momentan bis zu drei), dann würde sich das alles um eins verschieben. Wie wahrscheinlich das jetzt noch ist, wo ein Großteil der Parameter dekodiert ist, ist eine andere Frage, nur ausschließen würde ich es nicht. Was Dir lieber ist.

Und was meinst Du mit den möglichen Werten? Die sind in /K ja auch nicht hinterlegt (und auch sonst nirgendwo). Die Therme weist aber unzulässige Werte von selber zurück, bzw. gibt eine (allgemeine) Fehlermeldung zurück.

Das mit Safari ist seltsam, bist aber sicher, dass es Parameter 0 und nicht 5 oder 6 ist (wo ja nur Tag und Monat stehen)?

Was das Flashen angeht: Die ganzen De-/Aktivierungsmöglichkeiten für bestimmte Funktionen stammen noch von Gero und sind eigentlich nicht nötig. Ich würde höchstens IPWE (aus Sicherheitsgründen) und MAX_CUL (weil hierfür eine IP definiert werden muss) deaktivieren. DHT und DS18B20 würde ich aktivieren und mit gängigen Pins definieren, dann kann das jeder problemlos nutzen, wenn er einen Sensor anschließt.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

justme1968

ok. ich mache dir vorschläge für beides.

wenn sich (auch nur möglicherweise) etwas ändert dann lieber doch die strings. aber wenn möglich nicht als html.

wenn ich mit /Kxx eine kategorie abfrage bekomme ich (je nach wert) in der rechten spalte z.b. drop down menüs an denen ich die möglichen werte sehe.


ja. parameter 0. bild hängt an.


dann würde ich wenn es so weit ist so eine allgemeine firmware als hex file mit einchecken.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Schotty

Zitat von: freetz am 19 Februar 2018, 19:56:08
Wie wahrscheinlich das jetzt noch ist, wo ein Großteil der Parameter dekodiert ist, ist eine andere Frage, nur ausschließen würde ich es nicht.
Bisher sind von den aktuelleren Reglermodellen (bspw. BOBs&WOBs RVS43.325) noch nicht alle (neuen oder erweiterten) Parameter dekodiert. Auch in Zukunft dürfte es imho immer wieder mal neue oder veränderte/erweiterte Parameter geben, die mit einer neuen Regler- oder gar Software-Version auftauchen.

Zitat
Was das Flashen angeht: Die ganzen De-/Aktivierungsmöglichkeiten für bestimmte Funktionen stammen noch von Gero und sind eigentlich nicht nötig. Ich würde höchstens IPWE (aus Sicherheitsgründen) und MAX_CUL (weil hierfür eine IP definiert werden muss) deaktivieren. DHT und DS18B20 würde ich aktivieren und mit gängigen Pins definieren, dann kann das jeder problemlos nutzen, wenn er einen Sensor anschließt.
Da ich mich mit dem Flashvorgang via FHEM absolut nicht auskenne: Ließen sich dann die erwähnten Funktionen optional auch wieder aktivieren? Wie sieht es mit zusätzlich genutzten Pins aus, bspw. für Relais-Shields oder angeschlossene Koppelrelais?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

justme1968

deshalb  entweder doch strings, oder an irgend einer stelle eine tabelle um die zuordnung der enums ein mal auszulesen.

das flashen aus fhem besteht aus drei teilen. ein mal dem kommando im modul, ein mal einer default firmware und drittens der möglichkeit beim kommando immer auch ein eigenes hex file anzugeben. es ist also kein problem das auch eigene konfigurationen zu verwenden. und wer es weiter so machen möchte wie bisher kann das natürlich auch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

freetz

@Schotty: Neue Parameter bedeuten aber nicht zwangsläufig neue Einheiten (um die ging es Andre). Aber es stimmt schon, dass ich es nicht ganz  auszuschließen ist und von daher die Strings die sicherere Variante wären.
@Andre: Auf die beiden HTML-Entities kann ich seltsamerweise nicht verzichten, da ich es in der Arduino IDE nicht hingekriegt habe, an den betreffenden Stellen z.B. ein Prozentzeichen (das ja eigentlich sogar noch zum 7-Bit ASCII Standard gehört), darzustellen, egal wie ich es escaped habe. Beim Gradzeichen sieht es ähnlich aus. Letztlich ist es aber der regular expression doch egal, ob ich s/\&perc/<FHEM ID>/; oder einen anderen String ersetze. Letztlich hat FHEM dann doch den Luxus nicht mit 8kB Variablenspeicher und 256kB Flash auskommen zu müssen, von daher bin ich froh um jede Tabelle oder Funktion, die nicht noch zusätzlich Platz benötigt.

Ich überlege gerade, ob ich Dir eine ansonsten undokumentierte Funktion einbaue, die auf einer Seite alle Parameter mit Kategorien und evtl. vorhandenen Parameterwerten auswirft. Denn nur deswegen (und dann womöglich noch in regelmäßigen Abständen) einmal die mehr als 1000 Parameter aufzurufen, die dann ja auch immer an die Therme geschickt werden, wäre dann doch ein Overkill. Was meinst Du?
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

justme1968

ich habe die ausgabe im sketch mal probehalber auf meinen vorschlag von oben umgestellt:{
  "6225": {
    "Value": "96 ",
    "Unit": "",
    "DataType": 0
  },
  "6226": {
    "Value": "100 ",
    "Unit": "",
    "DataType": 0
  }
}


ich denke das macht es einfacher zu parsen. auch später für den sketch wenn parameter gesetz werden.

dabei ist mir noch folgendes aufgefallen:
- die werte werden immer als string geschickt. auch wenn es eigentlich zahlen sind. ist das absicht? könnte man das ändern? d.h. data type 0 als zahl.
- manche strings haben am ende jeweils noch ein leerzeichen. ist das absicht?
- du hast oben eine private routine vorgeschlagen um einmalig an alle parameter und kategorieren zu kommen.
  wie wäre es statt dessen die json ausgabe etwas zu erweitern:
  - optional auch bereiche angeben. also z.b. so: ..../J=5700-5799,6225,6226
  - optional auch die abfrage der kategorien über json: .../J=K und .../J=K0,K1
dann würde ich mir die komplette konfiguration selber häppchen weise holen und das board ist nicht auf einen schlag für lange zeit belegt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

freetz

- Ich schicke es deswegen als String, um nicht vorher groß prüfen zu müssen, um was es sich handelt. Ich kann aber für DT=0 nur die Zahl senden.
- Das Leerzeichen ist keine Absicht, ich versuche das mal wegzubekommen.
- Das Auflisten von Parametern und Kategorien ist keine große Arbeit, weil ich nur einmal eine Schleife über das gesamte Array laufen lassen muss. Dann aber noch Bereiche und/oder Kategorien abzubilden, ist (mir) zu viel Arbeit, weil diese Funktionen dann wieder anderswo hängen. Bitte nicht vergessen, dass das ganze Projekt organisch gewachsen ist. Da sind nicht immer bis ins kleinste Glied eigenständige Aufgaben auch in eigene Funktionen ausgelagert worden. Das führt auch an anderen Stellen zu dirty hacks, die dann wiederum weitere nach sich ziehen. Das möchte ich gerne vermeiden. Außerdem ist der Arduino bei der Gesamtausgabe von Parametern und Kategorien (ohne Abfrage der Werte wohlgemerkt) deutlich schneller "zurück", als bei allem, was auf den Bus zugreift.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

justme1968

die zahlen als zahl statt string wäre schön. danke.

leerzeichen sind nicht wirklich schlimm. ist mir nur aufgefallen.

dann vergessen wir die bereiche erst mal, wenn man aber mit .../J=K alle kategorien und mit .../J=Kxx jeweils eine komplette kategorie als json bekommen kann wäre das schön.

bitte meine vorschläge und wünsche nicht falsch oder als kritik verstehen. der anwendungsfall 'so gut wie möglich mit einer externen software' zu integrieren ist einfach neu. da fallen ein paar dinge einfach eher auf als bei der normalen bedienung von hand.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

wenn das mit der kategorien ausgabe per json ok ist würde ich noch einen vorschlag für das format machen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

freetz

Ja, das mit der JSON-Ausgabe ist ok - ist ja nur für diesen Zweck, insofern ist das, was ich davor oder dahinter schreibe, egal.
Zahlen kommen jetzt als Zahl, aktualisierte Version ist auf GitHub.

Und klar, verstehe ich schon alles und würde es mir auch oftmals anders wünschen, und wenn sich jemand anderes die Mühe machen will, dann gerne, der Code ist ja offen und auch nicht allzu schwer zu lesen (als ich das von Gero übernommen habe, war das mein erstes C-Programm, das mehr als ein paar Dutzend Zeilen hat, und ich hab's auch hingekriegt, obwohl ich von Perl kommend viele Strukturen in C immer noch nicht ganz durchblicke ;) ). Nur für mich haben andere Dinge in dem Projekt halt (bei meinen inzwischen eher begrenzten Ressourcen) Priorität...
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

justme1968

anbei mal ein kurzer einblick in welche richtung das ganze geht. auf den screenshots sieht man die device detail ansicht, die liste der kategorien ist ausgeklappt und dort die kategorie 37, es sind ein paar parameter ausgewählt die regelmässig abgefragt werden. zusätzliche parameter kann man einfach durch anklicken an oder abwählen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

FunkOdyssey

Sieht sehr gut aus. Dann erspare ich mir vielleicht meine Optimierungen an meiner dazugehörigen HTTPMOD-Konfiguration. Ich habe in den letzten Tagen fleissig umgeräumt. Und immer im Hinterkopf, dass sich das vielleicht bald erledigt hat. :-)

Falls es noch von Interesse ist - hier noch ein paar Feature Requests:
- evtl. keine Punkte in den Readingsbezeichnungen
- unterschiedliche Intervalle für die verschiedenen "polls" (nicht wichtig, aber vielleicht in einer sehr viel späteren Ausbaustufe interessant)

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

FunkOdyssey

Es gab mal Zeiten (siehe diesen Thread), da habe ich die Broetje-Therme verflucht. Mittlerweile ist die AFAIK besser integriert, wie alles andere. :-)

freetz

Ok, das ist ja wirklich der Hammer :)! Vielleicht überdenke ich da doch noch mal meine Prioritäten ;)...
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan