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

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

Vorheriges Thema - Nächstes Thema

Schotty

#30
Jaaaaaaa das sieht guuuut aus!  ;D ;D
Blendest oder graust du die error7-p.n.s.-Parameter bei den Auswahllisten gerätespezifisch aus? Oder tauchen die in der Auswahlübersicht als auswählbar mit auf? Nur so ein Gedanke, dass da hinterher nicht die lauten Aufschreie kommen, weshalb denn bei Parameter xy (der eigtl vom spezifischen Regler gar nicht unterstützt wird bzw. nicht verfügbar ist) immer eine Fehlermeldung kommt.. ;)

Machst du zufällig auch eine solche click&play-Auswahl bzgl zu loggender Parameter? Die dann wiederum aufgeteilt in FHEM-db-logs und Kartenlogs?

Mir ging noch durch den Kopf, dass es auch toll wäre, wenn man Parameter auswählen und davon 24h/48h/Wochencounter anzeigen lassen könnte, bspw. Brenner-&TWW-Takte, Laufzeiten von verschiedenen Erzeugern/Verbrauchern etc. (Achso, damit meine ich nicht die 24h-Durchschnittswertfunktion, sondern wirklich einen Zähler, der dann nach Intervall x zurückgesetzt wird, aber bspw. noch eine gewisse Zeit danach verfügbar ist, bspw um bei einer Übersicht die Brennertakte&Laufzeiten von heute, gestern und pro Woche anzeigen zu lassen - unabhängig von einem Log.)

Da kommen bestimmt noch mehr Ideen - wie gesagt, alles was man eh mit FHEM lösen kann/muss, bitte ignorieren bzw. dementsprechend kommentieren.. ;)

DANKE!!!

PS: Frischer RPi ist eingetroffen - dann muss ich mich mit der Installation&Reaktivierung von FHEM ja anscheinend beeilen..! ;)
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Schotty

Zitat von: freetz am 20 Februar 2018, 17:10:29
Ok, das ist ja wirklich der Hammer :)! Vielleicht überdenke ich da doch noch mal meine Prioritäten ;)...

;D ;D ;D
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

justme1968

@Schotty: einziges davon geht direkt mit fhem bordmitteln. aber manches kann man über das modul vielleicht einfacher anlegen als von hand.

zu den nicht unterstützen parametern: die wollte ich komplett ausblenden. ich weiss nur noch nicht wann und wie genau ich festellen kann das eine parameter nicht unterstützt ist. ich vermute das geht erst nach dem das board tatsächlich versucht hat diesen paramter über den bus zu lesen? das würde bedeuten das sie in der initialen abfrage der kategorien noch nicht markiert werden können.

in der json abfrage kommen aktuell leere felder zurück. wäre es nicht sinnvoll hier einen fehler zu liefern? z.b. so: { ..., "<id>": { "error": "not supported" }, ... }

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

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

justme1968

hier ein vorschlag für das json format der kategorien:{ "0": { "name": "Uhrzeit und Datum", "min": 0, "max": 6 },
  "1": { "name": "Bedieneinheit", "min": 20, max": 70 },
  "2": { "name": "Funk", "min": 120, "max": 140 }, ... }


und für die parameter einer kategorie entweder einfach:{ "8300": "Diagnose Erzeuger - 1. Brennerstufe T2",
  "8301": "Diagnose Erzeuger - 2. Brennerstufe T8",
  "8302": "Diagnose Erzeuger - Zustand Brennerklappe Auf", ... }


oder etwas umfangreicher: für jeden parameter als value nicht nur den namen des parameters sondern einen hash mit namen, datentyp und einheit. dann könnte man bei der abfrage der werte datentyp und einheit weg lassen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

freetz

#34
Ok, ich schau' mal - Du wolltest aber doch auch noch die möglichen Optionen eines Parameters (wie bei den Dropdowns) übermittelt bekommen, wo/wie sollen die erscheinen? Datentyp und Einheit möchte ich lieber für andere Anbindungen in der Antwort auf eine Parameteranfrage belassen.
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

Schotty

#35
Zitat von: justme1968 am 20 Februar 2018, 21:15:08
@Schotty: einziges davon geht direkt mit fhem bordmitteln. aber manches kann man über das modul vielleicht einfacher anlegen als von hand.
Super, einfacher ist immer gut ;)

Zitat
zu den nicht unterstützen parametern: die wollte ich komplett ausblenden. ich weiss nur noch nicht wann und wie genau ich festellen kann das eine parameter nicht unterstützt ist. ich vermute das geht erst nach dem das board tatsächlich versucht hat diesen paramter über den bus zu lesen? das würde bedeuten das sie in der initialen abfrage der kategorien noch nicht markiert werden können.
Ich denke, dass freetz eben genau das anhand der Gerätefamilien&-varianten (Parameter 6225&6226, nur via Adapter abrufbar) gelöst und daher auch gerade die jüngsten Änderungen im code hinsichtlich der Berücksichtigung der Gerätevariante vorgenommen hat.  @freetz: Korrekt?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

justme1968

dann vergiss die variante eins für die parameter. in variante zwei wäre auch dafür platz:

{ "<id>": { "name": ..., "unit": ..., "dataType": ..., "possibleValues": ["on", "off",...]}, "<id2>": ...}
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

freetz

Also nur zum sicheren Verständnis:

Das hier bleibt:
{ "0": { "name": "Uhrzeit und Datum", "min": 0, "max": 6 },
  "1": { "name": "Bedieneinheit", "min": 20, max": 70 },
  "2": { "name": "Funk", "min": 120, "max": 140 }, ... }


Und das kann weg:
{ "8300": "Diagnose Erzeuger - 1. Brennerstufe T2",
  "8301": "Diagnose Erzeuger - 2. Brennerstufe T8",
  "8302": "Diagnose Erzeuger - Zustand Brennerklappe Auf", ... }


Wenn ich das hier:
{
  "6225": {
    "Value": "96 ",
    "Unit": "",
    "DataType": 0
  },
  "6226": {
    "Value": "100 ",
    "Unit": "",
    "DataType": 0
  }
}


um das hier erweitere:
"possibleValues": ["on", "off",...]

Das bedeutet aber, dass Du die möglichen Werte nur bekommst, wenn Du diese vorher abfragst - und das eben in halbwegs regelmäßigen Abständen, weil sich da immer mal was ändern kann (setzt natürlich ein Firmware-Update voraus). Ich dachte, die Idee wäre, an die Infos zu kommen, ohne den Bus zu belegen. Aber letztlich ist beides für mich ok (und die letzte Variante wahrscheinlich noch einfacher umzusetzen, weil ich da eh' schon in dem jeweiligen Datensatz drin bin).
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

#38
1. bleibt und ist dir ausgabe von .../J=K

vorschlag 2. kommt weg und wird ersetzt durch die umfangreichere variante { "<id>": { "name": ..., "unit": ..., "dataType": ..., "possibleValues": ["on", "off",...]}, "<id2>": ...}
als antwort auf .../J=Kxx.

d.h es gibt eine abfrage um alle kategorien abzufragen und eine zweite um alle parameter einer kategorie abzufragen. bei der abfrage aller parameter einer kategorie sollte alles mit kommen das schon bekannt ist. dataType, unit, possibleValues. alles was geht ohne den bus zu belegen.

3. die abfrage eines bestimmten wertes muss dann nur noch liefern was die abfrage einer kategorie nicht liefern kann.

2. und 3. verwenden das gleiche format. 2. mit allem was ohne bus geht, 3. mit bus.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

freetz

Zitat von: Schotty am 20 Februar 2018, 22:20:04
Ich denke, dass freetz eben genau das anhand der Gerätefamilien&-varianten (Parameter 6225&6226, nur via Adapter abrufbar) gelöst und daher auch gerade die jüngsten Änderungen im code hinsichtlich der Berücksichtigung der Gerätevariante vorgenommen hat.  @freetz: Korrekt?

Jein. Denn letztlich ruft man ja mit 6225/6226 nur die Geräteidentifikation ab. Man könnte mit etwas geparse einfach die _defs.h an das Modul andocken und da dann schauen, welcher Parameter zu welcher Therme gehört. Andernfalls bleibt nur ein Komplettabruf aller Parameter.

Das mit der Error-Übermittlung ist auch nicht so einfach, da sich hier BSB und LPB im Umfang der Rückmeldung unterscheiden, und teilweise auch innerhalb der Systeme. Schottys LPB gibt keine weiteren Fehlerinformationen zurück, bei BSB aber schon. Andere LPB-Systeme sind bei Fehlermeldungen ähnlich "gesprächig" wie normale BSB-Systeme. Bei den "schweigsameren" Systemen kann man dann aber nicht unterscheiden, ob ein Parameter nicht unterstützt wird oder ob die Kommunikation generell fehlgeschlagen ist (außer daran, dass dann alle anderen Parameter wohl auch Fehler werfen würden). Da also etwas Sinnvolles, Busübergreifendes zu übermitteln außer "Fehler" wird schwierig.
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

freetz

Wie sollen die ENUMs denn übermittelt werden? On/Off, Closed/Open, Yes/No etc. wird über ein eigenes DataType definiert, da kann/braucht es ja keine weiteren Texte. Aber wie soll z.B. "0 - Schutzbetrieb", "1 - Komfortbetrieb" etc. übermittelt werden?
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

Schotty

Zitat von: freetz am 20 Februar 2018, 23:14:32
Jein. Denn letztlich ruft man ja mit 6225/6226 nur die Geräteidentifikation ab.
Das ist klar. Aber anhand der Ausgaben davon (bspw 96/100) hast du doch (abgesehen von DEV_ALL) in der _defs.h die Zuordnungen gemacht und gibst ggf. Parameter von /Q frei, oder nicht?

Zitat
[...] _defs.h an das Modul andocken und da dann schauen, welcher Parameter zu welcher Therme gehört. [...]
Das meinte ich mit 'anhand 6225&6226 gelöst'.
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

justme1968

für die enums gibt es glaube ich zwei möglichkeiten: entweder wird genau das gesendet was auch bei set verwendet werden muss. oder (vor allem wenn das nicht lesbar ist) brauchen wir noch irgendwo eine abfrage um die zuordnung zwischen wert und angezeigtem text zu bekommen. das könnte auch in dem possibleValues array sein in dem man statt nur einzelnen werten wertepaare (hash oder array) schickt. also noch eine ebene tiefer schachtelt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

freetz

Set erwartet numerische Werte, keinen Text (weswegen auch etwa 10% der Parameter nicht gesetzt werden können).
Wenn ich das in "possibleValues" integrieren soll, dann schick' bitte auch dafür noch ein Template. Ich arbeite sonst nicht mit JSON, deswegen macht es wenig Sinn, wenn ich da herumprobiere, bis es passt...
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

freetz

So, da mir die Zeit etwas davon rennt, habe ich jetzt doch noch mal etwas herumgestochert, das Ergebnis ist jetzt auf GitHub.
Ich musste bei value doch wieder auf Anführungszeichen umschwenken, da es dort auch die Rückgaben "---" (für nicht gesetzt) bzw. "unknown type" geben kann (wo also noch nicht klar ist, um welche Einheit es sich handelt.
Die Error-Meldungen kann ich auch nicht so ohne weiteres ausgeben, aber da der Rückgabestring bei solchen Fehlern (also "sicheren" Fehlern) NULL ist, blende ich diese dann gleich aus, zumindest, wenn man mit /JK=xx eine einzelne Kategorie abruft.
Mit /JK=ALL kommen alle Kategorien mit min/max.
Zwischen /JK und /JQ gibt es bisher noch keinen Unterschied, d.h., auch /JK zieht immer auch gleich die Werte über den Bus. Da aber "ohne Bus" auch die "parameter unknown" mit gelistet würden, ist das vielleicht sogar ganz sinnvoll. So oft wird man die reine Parameterausgabe dann vielleicht auch nicht abrufen?
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