FHEM Forum

ich mache diesen thread mal auf um ideen und wünsche für ein potentielles fhem modul für das bsb board zu sammeln.

das modul würde dann statt der aktuellen http anbindung verwendet werden können (im prinzip unabhängig von der angesprochenen json erweiterung. aber diese würde manches etwas einfacher machen).

also los ...


edit 2018-03-01: anbei eine erste version des moduls.
- die beiden jQuery files müssen nach .../www/pgm2
- das modul nach .../FHEM
- auf dem arduino muss der neueste BSB_lan sketch von heute drauf sein

danach anlegen mit define <name> BSB <ip>

danach verbindet sich fhem mit dem board und fragt ein mal die verfügbaren kategorien ab. man kann jetzt entweder das polls attribut von hand setzen, oder in die device detail ansicht gehen und die kategorien aufklappen. sobald für eine kategorie auf die parameter spalte klickt werden die verfügbaren parameter geholt und die betreffende kategorie aufgeklappt. das dauert je nach anzahl der parameter ein paar bis mehrere sekunden. nicht ungeduldig werden. zum ersten testen am besten kategorie 0 verwenden. die geht schnell. über die checkbox in jeder parameter zeile legt man fest ob der betreffende parameter regelmässig ausgelesen werden soll.

am besten verbose für das device auf 4 setzen. dann sieht man im log was passiert.

aktuell werden die werte fest alle 30 sekunden abgeholt. das wird noch konfigurierbar, und es wird mehrere intervalle für mehrere parameter gruppen geben.

die reading namen sind oft noch nicht fhem konform. außer warnung sollte das erst mal keine negativen auswirkungen haben.

die interaktiven klicks auf die checkboxen werden noch nicht browser übergreifend synchronisiert. also am besten nur ein fenster mit dem bsb device offen haben.

mit get <name> parameter <id> kann man gezielt einen (oder mehrere) parameter von hand abfragen.

das modul arbeitet komplett nonblocking.

viel spass damit. mal sehen wie viele anwender es wirklich gibt :)


was noch kommt:
- readings fhem konform machen
- mehrere parameter gruppen die mit unterschiedlichen intervallen abgefragt werden.
- setzen von paramtern
- mehr info im frontend über das was das modul gerade macht
- flashen aus fhem heraus
- mehr als ein offenes browser fenster
- ... ?

edit 2018-03-02: perl fix

edit 2018-03-05: multi tab js error fix, table layout fix

edit 2018-03-06: encoding fix, busy indicator

edit 2018-03-17: fhem-konforme reading namen

edit 2018-03-20: neues attribut readingsFormat

Hach, ein Traum wird wahr. Vielen Dank für dein Engagement.

Ich weiß gar nicht wo ich anfangen soll. Je länger ich darüber nachdenke, desto voller wird die Wunschliste.

- Arduino Mega über das Modul flashbar (z.B. analog avrdude in ArduCounter)
- Parametrisierbare Konfiguration (Raumgerät, PINs, Shields, etc.)
- Standards wie disable, Interval, TimeOuts, etc.
- Auch Setter für Präsenztaste, TWW-Push, Raumtemperatur
- Benutzerauthentifizierung (SHA256 analog allowed?), damit die Kennwörter nicht im Klartext angezeigt werden

Großartig! Danke im Voraus!

Eine Beschreibung der Einbindung/Nutzung/Konfiguration des Moduls würde ich dann gerne im BSB-LAN-Handbuch mit aufnehmen.

Bei meiner Wunschliste bitte ich zu berücksichtigen, dass ich quasi FHEM-noob bin - also Quatsch-Wünsche bitte einfach ignorieren.. ;)

Die ersten Gedanken:
- prinzipiell sämtliche URL-Befehle via Modul nutzbar
- am Adapter angeschlossene oder auch bereits bei FHEM installierte Sensoren (wie bspw. Temp etc) einzeln/gesammelt verfügbar machen
- einfache Erstellung von Logs für frei auswählbare Parameter und ggf zusätzliche TempSensoren
- einfaches Übermitteln von einzelnen/gemittelten Raumtemperaturen für die Nutzung des Raumeinflusses
- Warnanzeige und Push-Mitteilungsfunktion für auswählbare Parameter - speziell Fehler- & Störungsmeldungen, oder auch bei der Über- oder Unterschreitung bestimmter Werte (Temps, Druck, Spannung etc) bzw Zustände (Kontakt Hx offen/geschlossen) (optional: abspielbare Alarmsounds oder sowas..?)
- Status-Abruf und -Änderung von zusätzlich angeschlossenen Koppelrelais (Abfragen) und Relaisboards (Setzen/Abfragen)

..und bestimmt noch viel mehr.. ;)
Gruß

Ich habe jetzt in BSB_LAN den JSON-Export integriert (über URL /J=a,b,c,d...) Kannst Du mal schauen, ob das so für Deine Zwecke passt?
Und für das Setzen der Parameter: Wie übermittelst Du die JSON-Struktur? Als application/x-www-form-urlencoded? Oder als application/json (was vermutlich einfacher für mich wäre, wenn klar ist, dass der gesamte Request-Body (nur) die JSON-Struktur enthält?
Und welche Form von Antwort würdest Du benötigen (je weniger, desto besser ;) )?

Gruß,

F.

ja. mache ich. dauert aber noch etwas.

beim setzen: du hast die wahl. ich hatte aber an application/json gedacht. nur json im body.

ich denke im sketch ist es auch nicht nötig einen kompletten json parser zu implementieren. den string von vorne nach hinten durchzugehen und dann jeweils einen parameter nach dem anderen zu verarbeiten sollte reichen.

ich habe mir das setzen bisher überhaupt noch nicht angeschaut. als antwort 'reicht' im prinzip ein ok. je mehr sinnvolle antwort möglich ist um so besser.

Ja, das habe ich mir auch so gedacht - letztlich wird es ja nur zwei Variablen geben, Parameter und Wert, und letzterer wird immer numerisch sein, da kann ich dann wirklich relativ einfach den String durchgehen und müsste bei application/json noch nicht einmal url-decoding machen, wenn ich das richtig sehe.

ja. genau. und wenn mehr als ein parameter im gleichen json gesetzt wird kann man einfach alle der reihe nach verarbeiten.

Habe ich jetzt auch schon rudimentär so umgesetzt, vielleicht kriege ich das noch am WE fertig. Muss aber die Anzahl der maximal gleichzeitg in einem JSON zu bearbeitenden Parameter auf 20 begrenzen, da die Abarbeitung des HTTP-Requests vor der eigentlichen Befehlsverarbeitung passiert und ich so die geparsten Werte erst einmal zwischenspeichern muss. Aber mit 20 pro Aufruf sollte das wohl für die allermeisten Zwecke ausreichen.
Ich überlege gerade, die Abfrage von Parametern statt über die Auflistung in der URL auch über ein POST mit JSON-Struktur umzusetzen. Würde Dir das die Sache erleichtern oder ist der Abruf über URL und Auflistung der Parameter (/J=8700,5950,...) ausreichend?

Bzw., falls jemand anders da Ahnung hat: Wie machen andere Systeme das am liebsten (openHAB, Domoticz), wenn die per JSON Abfragen machen wollen? Mehr oder weniger statische URL oder die Abfrage als JSON liefern?

wer hätte gedacht das du dich jetzt so beeilst :) ich brauche auf jeden fall noch eine ganze weile bis ich wirklich anfangen kann mit dem modul :(

post mit json wäre glaube ich konsistenter und vielleicht auf für andere systeme einfacher umzusetzen.

Es wäre ganz gut wenn das Modul den Arduino etwas überwachen könnte. Zum Beispiel einen Zeitstempel sichern wenn es einen ungewollten Reset gab.

So, die JSON-Schnittstelle bei BSB-LAN läuft jetzt folgendermaßen:

1. über den URL-Befehl /J=a,c,b,d..., wobei a,b,... Parameter sind, die exportiert werden sollen.
2. Per HTTP POST Aufruf der URL /JQ (für Abfragen) und /JS (für das Setzen von Parametern). Folgende Parameter sind dabei möglich:
/JQ:
Senden:
"Parameter"
Empfangen:
"Parameter"
"Value"
"Unit"
"DataType" (0 = Zahl, 1 = ENUM, 2 = Wochentag, 3 = Stunde/Minute, 4 = Datum/Uhrzeit, 5 = Tag/Monat, 6 = String

/JS:
Senden:
"Parameter"
"Value" (nur numerisch)
"Type" (0 = INF, 1 = SET)
Empfangen:
"Parameter"
"Status" (0 = Fehler, 1 = OK, 2 = Parameter read-only)

Für nicht-numberische Werte beim Setzen von Parametern müsste ich die Erkennung ziemlich aufbohren; der einzige sinnvolle Einsatzzweck wäre m.E. das Setzen von Datum/Uhrzeit (wobei ich das noch gar nicht ausprobiert habe, ob das von BSB-LAN überhaupt so schon unterstützt wird) sowie etwaige Ferienprogramme. Wobei sich letztere vermutlich eh' besser über FHEM abwickeln lassen, als dabei dann auf die Therme zurückzugreifen.

ich habe gerade mal mit dem modul angefangen. hier direkt ein paar anmerkungen:

- das auslesen per json geht. das format ist aber noch nicht ideal. besser wäre ein hash. etwas so:
{ "<param>": { "value": <value>, "unit": <unit>, "dataType": <dataType>}, "<param2>": {...} }

- man könnte überlegen value, unit und dataType einfach mit v, u und d abzukürzen. das mach den json
  string deutlich kürzer

- du schickst in unit die einheit als html text mit. besser wäre nur ascii, oder ein enum.

- es wäre gut wenn man auch alle anderen seiten ohne html (d.h. nur als formatiertes ascii) auslesen könnte.
  bsp: das modul liest beim ersten connect die konfig seite und dann alle vorhanden parameter
  die config seite zu debug zwecken und natürlich um die sketch konfiguration auszulesen.
  das html format das zurück kommt macht aber das parsen aufwändig und fehleranfällig gegenüber änderungen

- es scheint nirgendwo (auch auf der config seite nicht) eine ausgabe über das erkannte modell zu geben
  d.h. das was der sketch beim starten auf der konsole ausgibt

ich hoffe das klingt nicht zu schrecklich... aber wenn das ziel ist das board automatisiert und auch von
anderen system aus zu verwenden dann sollten alle möglichen informationen so maschinen lesbar wir
möglich zu bekommen sein.

gruss
  andre

Also das Format der Ausgabe kann ich gerne anpassen, aber bei den anderen Punkten bin ich eher skeptisch. Schon jetzt ist es aufwändig, die Seiten in deutsch und in Englisch zu pflegen, dazu kommt, dass für viele der Hauptaspekt zu sein scheint, es (auch) standalone laufen zu lassen, so dass man auf die HTML-Seiten nicht verzichten kann, bzw. man diejenigen, die die Seite jetzt (erfolgreich) parsen, nicht zwingen sollte, ihre Parser neu zu konfigurieren.
Davon ab habe ich immer darauf geachtet, dass sich an der grundlegenden Struktur der Inhalts-Zeilen nichts ändert, weil die Thematik ja schon seit Anbeginn besteht.

Die meisten anderen Punkte lassen auch sicherlich schneller in Deinem Modul umsetzen:
- Die Geräteerkennung bekommst Du über die Parameter 6225 und 6226
- Die (wenigen) HTML-Einheiten sind fix und können mit Suchen/Ersetzen abgewickelt werden

Mein Beitrag für dieses Modul (was ich eine tolle Idee finde, auch wenn ich bisher ohne auskomme), ist der JSON-Export. Alles darüber hinaus gehende, kann gerne jemand in BSB-LAN integrieren, aber meine Ressourcen sind dafür zu begrenzt.

ok...

wenn du das json format für die ausgabe und für das setzen der werte noch anpassen kannst überlege mich mit für die anderen punkte noch etwas.

wäre es als kompromiss möglich bei der html ausgabe noch ein paar class attribute mit einzubauen?
z.b. in die tabelle am seiten anfang ein class=header, in die tabelle mit den eigentlichen daten ein class=content, in der liste der url befehle in die linke spalte ein class=cmd und in die rechte spalte ein class=descritpion. etwas ähnliches für die tabellen bei heizungsfunktion.

gerade wenn die seiten in unterschiedlichen sprachen kommen wäre es sehr hilfreich nur anhand der meta information zwischen den einzelnen komponenten einer zeile (kategorie/beschreibung/wert nzw. nicht unterstützt) unterscheiden zu können.


ich und vermutlich alle anderen die das board aktuell verwenden kommen ohne eigenes modul aus. ich denke aber das es mit einem modul und einem besser automatisierbaren interface noch einige anwender mehr geben kann.


ps: mit ist noch aufgefallen das zumindest im safari das eingabe feld für kategorie 0 nur mit tag und monat gefüllt wird. jahr und uhrzeit fehlen.

pps: zum flashen aus fhem heraus: bei anderen arduino modulen ist es so das die aktuelle firmware zum einen als tar file in contrib/arduino liegt und zum anderen als hex file in FHEM/firmware. letzteres wäre dann zwar immer eine version ohne besondere optionen, würde es einem einsteiger aber trotzdem erlauben recht schnell los zu legen. oder spricht noch etwas dagegen?

noch etwas vergessen: bei den json werten kommt aktuell nicht mir welche möglichen werte bei setzen verwendet werden können. falls du die z.b. als optionales possibleValues array noch mit in die json ausgabe eines wertes stecken kannst könnte ich ganz auf die html abfrage mit /K... verzichten. dann wäre die class attribute bei der heizungsfunktion natürlich komplett unnötig.

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.

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.

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?

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.

@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?

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.

- 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.

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.

wenn das mit der kategorien ausgabe per json ok ist würde ich noch einen vorschlag für das format machen.

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...

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.

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)

alles schon vorgesehen :)

Es gab mal Zeiten (siehe diesen Thread (https://forum.fhem.de/index.php/topic,45703.msg374675.html)), da habe ich die Broetje-Therme verflucht. Mittlerweile ist die AFAIK besser integriert, wie alles andere. :-)

Ok, das ist ja wirklich der Hammer :)! Vielleicht überdenke ich da doch noch mal meine Prioritäten ;)...

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..! ;)

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

@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" }, ... }

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.

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.

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?

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>": ...}

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).

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.

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.

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?

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'.

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.

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...

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?

sorry für die späte antwort. ich hatte ziemlich zu tun.

was die anführungszeichen angeht: die eigentlich korrekt umsetzung für json wäre es abhängig vom wert zu machen. d.h. zahlen ohne anführungszeichen und bei einem nicht gesetzten wert den value teil komplett weg lassen. wenn das zu aufwändig ist lass es wie es jetzt ist.

die komplette abfrage aller parameter würde ich nur ein mal beim start machen. vermutlich sogar nur ein mal beim define. und natürlich auf kommando des anwenders.

ich melde mich sobald ich deine aktuelle version probiert habe.

@justme1968: Implementierst du auch (bekannte) BC-readings (broadcasts)? Damit könnte man sich evtl einige Abfragen sparen, da bspw Brenner- und TWW-Stati und -Statusänderungen regelmäßig über den Bus laufen. Meist ist bei der heizungsseitigen Bedieneinheit bspw auch die Kesseltemp als stetig angezeigter Wert eingestellt (bei RGTs wiederum die Raumtemp), die geht dann auch so ca alle 10Sek über den Bus.

im prinzip ja. aber wie ich das sehe komme ich da aktuell nur per usb ran und nicht übers netz.

wenn das broadcasts sind wäre es schön wenn das board die z.b. per udp broadcast ins netz schickt. dafür gibt es sogar schon fertige module auf fhem seite. ich schaue mir das mal an.

Nur via USB? Meinst du im SerMo der ArduIDE? Mittels Einstellungen in der _config.h lassen sie sich zumindest auf mSD-Karte loggen. Aber da kennt sich freetz besser aus.. ;)

Die relevanten Broadcasts (Brennerstarts und -laufzeit etc.) können jetzt schon ausgewertet auf der Weboberfläche abgerufen werden. Ich sehe da keinen Gewinn, dafür aber einiges an Arbeit (inkl. Konfigurationsmöglichkeit) und Speicherplatzverbrauch, wenn man das jetzt per UDP noch ins Netz schickt...

Zitat von: freetz am 26 Februar 2018, 14:24:21
Die relevanten Broadcasts (Brennerstarts und -laufzeit etc.) können jetzt schon ausgewertet auf der Weboberfläche abgerufen werden.

Bezieht sich aber doch nicht auf die jeweiligen Stati, bspw. Brenner AN/AUS, Kesseltemp, TWW geladen etc. für eine permanente Anzeige im Modul?

Richtig, aber der Status lässt sich, wo vorhanden, verlässlicher über die entsprechenden Parameter auslesen. Wenn ein BC kommt, wenn der Arduino gerade etwas anderes macht (Webseite aufbauen, Daten loggen oder UDP-Pakete verschicken ;) ), dann geht der BC unerkannt am Arduino vorbei. Und auf so etwas würde ich mich nicht verlassen wollen. Aber wenn der Memory-Footprint des UDP-Moduls zu vernachlässigen ist und das jemand implementieren will, dann gerne. Nur ich werd's nicht machen können...

Zitat von: freetz am 26 Februar 2018, 14:57:36
Richtig, aber der Status lässt sich, wo vorhanden, verlässlicher über die entsprechenden Parameter auslesen. Wenn ein BC kommt, wenn der Arduino gerade etwas anderes macht (Webseite aufbauen, Daten loggen oder UDP-Pakete verschicken ;) ), dann geht der BC unerkannt am Arduino vorbei.

Stimmt, daran habe ich nicht gedacht  :)

@freetz: ich habe gerade deine letze firmware geflashed und bin dabei die neuen aufrufe ins modul einzubauen.

dabei habe ich folgende probleme:

- bei .../JK=xy fehlen die namen der einzelnen parameter. ist das absicht und ich habe etwas übersehen?

- ganz allgemein hat sich der arduino einige male komplett aufgehängt. ich weiss noch nicht genau woran das liegt.

scheinbar macht die parameter abfrage per json mit .../J=... probleme.

bei .../J=8310 sehe ich per usb noch GET /J=8310 HTTP/1.1
/J=8310

und das war es.

Gibt nur noch JQ, dafür aber auch per URL...

du meinst .../J= geht nicht mehr? in der beschreibung der befehle steht es noch drin.

mit .../JQ=xy stimmt aber leider auch etwas nicht. alle abfragen die ich damit versucht habe landen in einer endlosschleife.


aber noch mal zurück zu .../JK=xy und dem fehlenden namen. aktuell macht das modul folgendes:

beim starten wird ein mal per .../JK=ALL die liste aller kategorien geholt. diese wird dann über ein attribut gefiltert und was übrig bleibt wird nach und nach ein mal pro kategorie mit .../JK=xy geholt. daraus wird dann im gui die liste zum zusammenflicken der abzufragenden parameter gemacht. hier brauche ich die namen. die fehlen aktuell. (ob diese liste dann komplett noch mal auf fhem seite gespeichert wird weiss ich noch nicht)

danach fängt dann die normale schleife an in der dann nur noch die ausgewählten parameter gepollt werden. hier reicht es dann die werte zu haben. ohne namen und ohne alles andere das immer gleich bleibt.

zum hängenbleiben: wäre es vielleicht sinnvoll im sketch einen watchdog zu haben der den atmega zurück setzt falls er aus irgendeinem grund hängen bleibt?

safari scheint bei der autocompletion der url schon dinge abzurufen die auch zum hängen bleiben führen.

Zitat von: justme1968 am 28 Februar 2018, 16:23:56
du meinst .../J= geht nicht mehr? in der beschreibung der befehle steht es noch drin.

Meinst du das Handbuch? Falls ja: Sorry, ist für mich auch gerade eine neue Info ;)

Zitat von: freetz am 28 Februar 2018, 16:04:45
Gibt nur noch JQ, dafür aber auch per URL...

Da ich mich ja bekanntermaßen nicht auskenne  ;D : Ist das "HTTP POST" in der Beschreibung (bei /JQ und auch bei /JS) im Handbuch dann obsolet..?

nein. in der ausgabe von .../O

/O kannte ich bis dato auch noch nicht  ;D ;D

da landet man wenn man auf der board seite URL-Befehle anklickt :)

LOL - jetzt wo du es sagst..  ;D

Zitat(ob diese liste dann komplett noch mal auf fhem seite gespeichert wird weiss ich noch nicht)

wenn du nicht speicherst, wird dann bei jedem fhem restart komplett neu gelesen?

ja. das ist aber eigentlich nicht wirklich schlimm. es dauert halt ein paar minuten wenn der filter nicht gesetzt ist.

wie oft startest du denn dein fhem neu? meins läuft monate lang.

da ich kein spezielles testsystem habe, kann es in seltenen fällen dann auch öfter vorkommen. aber in der regel nicht.

Also: /J ist rausgeflogen, weil ja eigentlich die Datenablieferung per HTTP-POST und application/json an /JQ und /JS gewünscht war und wir gleichzeitig nicht so üppig mit Speicherplatz ausgestattet sind. Mehr oder weniger durch Zufall habe ich durch einen Hinweis des polnischen Nutzers (der mich ursprünglich auf die JSON-Idee gebracht hat bzw. diese angefragt hatte) herausgefunden, dass meine Parsing-Routine so mit der heißen Nadel gestrickt ist, dass auch in der URL übermittelte Parameter geparst werden, also /JQ=a,b,c,d
In dem Fall stimmt "it's not a bug, it's a feature" mal wirklich ;).
Dass da eine Endlosschleife herauskam, war noch ein (echter) Bug, der jetzt gefixt ist.

Den Namen habe ich jetzt hinzugefügt, darüber hinaus bei ENUM-Parametern den aktuellen Wert in Value gepackt und die Beschreibung in desc.

Aufpassen muss man bei Typ 2 (DT_BITS), der aussieht, wie ein ENUM, aber immer ein 16-Bit Wert ist, bei dem das höherwertige Byte der entsprechende Wert ist und das niederwertige Byte die Bits markiert, die von dieser Änderung betroffen sind. Hintergrund ist, dass manche Einstellungen mehrere Bits belegen und dies dadurch herausgefiltert werden kann. Die Nummerierung der Typen hat sich dadurch etwas verschoben, für die aktuelle Liste siehe dt_types_t in der _defs.h

Ich habe jetzt alles soweit noch einmal getestet, und bei mir läuft's rund. Ein Watchdog wäre eine feine Sache, allerdings lässt sich das ja nicht so einfach wie beim ESP8266 umsetzen. Ich müsste in jeden länger laufenden Code eine entsprechende Markierung einbauen, da z.B. das Herunterladen der Logs schon mal ein paar Minuten dauern kann. Wenn das einer umsetzen will, dann jederzeit geren, ich würde ich nach dem Testen der JSON-Funktionalität den Code bei mir "einfrieren", so dass die Änderungen dann über einen pull request einfach eingebaut werden können.

Gruß,

F.

sehr schön die abfragen funktionieren jetzt. ich poste demnächst mal eine erste preview version des moduls.

eine kleinigkeit habe ich aber noch. bei der abfrage mit .../JK=xy kommt ganz am ende noch mal ein parameter der da nicht hin gehört. bei kategorie 0 ist es der parameter 0 der dann doppelt ist, bei kategorie 6 ist es ein parameter 6 der völlig falsch ist.

bei abfrage der gleichen kategorie mit ../K sind die zusätzlichen parameter jeweils nicht dabei.

Na, das ist ja schon mal was ;)...
Das mit dem Parameter am Ende ist seltsam - bei JK=31 stimmt alles, ebenso bei 3 und 11. Bei 0 und 6 kann ich den Fehler aber reproduzieren. Lag am letzten Schleifendurchlauf, gefixte Version ist auf GitHub.
Dann bin ich ja mal sehr auf das Preview gespannt :)...

wie angekündigt... im ersten beitrag gibt es eine test version :)

Danke! Leider klappt's bei mir nicht:

2018.03.02 08:05:07 1: reload: Error:Modul 98_BSB deactivated:
Experimental keys on scalar is now forbidden at ./FHEM/98_BSB.pm line 601.

Bei Neustart kommt nach dem Define
define ElcoThision BSB 192.168.1.50/1234
nur ein
Cannot load module BSB

Was mache ich falsch?

deine perl version ist zu neu. ich repariere es nachher.

...und das auf einer Synology ;)...
Aber die macht FHEM-bezogen auch anderweitig Probleme, z.B. bei Device::Serial, das ich auf Teufel-komm-raus nicht so kompiliert bekomme, dass es damit läuft, selbst mit der Synology Toolchain nicht (die mir immerhin ein "make" auf der Syno ermöglicht)...

BTW: Sebastian (der polnische User, der mich auf die JSON-Idee gebracht hatte) fragt, ob bei /JQ auch alle possibleValues mitgeliefert werden müssen, oder reicht Dir das, wenn das bei /JK=xx kommt? Dann würde ich /JQ etwas "entschlacken".
Umgekehrt kommt jetzt bei /JK=xx noch der Wert eines Parameters, da meintest Du glaube ich, dass das wiederum bei /JQ reichen würde, richtig?

Zitat von: freetz am 02 März 2018, 09:01:27
...und das auf einer Synology ;)...

Nee, bei mir auf meinen Debian-Stretch-System auch. :-)

hab oben eine neue version angehängt. damit sollte es gehen.

mir würde es reichen wenn bei /JK alles mit kommt was nicht veränderlich ist. d.h. der value kann entfallen.
bei /JQ hätte ich gerne alles was sich ändern könnte und den namen.

ps: für die intel synologys empfiehlt sich das active perl. das ist sehr vollständig. ich glaube es gibt sogar eine arm version die auf manchen arm synology läuft.

Wow.... geil, thumbs up!!!

Gibt es den Modul bereits per Update oder muss der manuell der Fhem Installation hinzugefügt werden?

Wie gestaltet sich der Umzug von HTTPMOD? Ich denke speziell an die ganzen DOIFs (Mit Referenzraumsimulation und Co.) Eine Stunde oder einen tag einplanen :)

Gruß

das modul gibt es erst mal nur hier im thread.

vor dem einchecken müssen noch die oben beschriebenen dinge behoben werden.

Wie komme ich mit dem Modul an den Arduino, wenn ich über Web normalerweise eine Authentifizierung durchführen muss und außerdem einen PIN hinterlegt habe?

Beispiel:
http://user:pass@iparduino/1234/

Irgendwie hatte ich es kurzzeitig geschafft. Ich sag auf jedenfall schon die Kategorien. Aber nun es gab noch keine Readings.

---

Nachtrag: Es scheint, als wäre der Arduino abgestürzt. Dieser lief (mit Ausnahme einer selbstverschuldeten Panne) sonst immer sehr stabil. Ich vermute, dass die JSON-Funktion den Arduino irgendwie zum Aufhängen gebracht haben. Sketch vom 01.02.2018.

---

Nachtrag 2:

Okay. Stimmt. Arduino war weg. Nun ist BSB wieder connected, aber dennoch gibt es folgenden Fehler:

2018.03.02 15:44:14.480 4: bsb: trying to poll.
2018.03.02 15:44:19.484 2: bsb: http request (http://user:pass@192.168.0.100/1234/JQ=0,5,6,6800,6801,6810,6811) failed: read from http://192.168.0.100:80 timed out

Zitat von: justme1968 am 02 März 2018, 10:40:38
mir würde es reichen wenn bei /JK alles mit kommt was nicht veränderlich ist. d.h. der value kann entfallen.
bei /JQ hätte ich gerne alles was sich ändern könnte und den namen.

Was meinst Du mit "sich ändern könnte"? Theoretisch können sich die possibleValues nach einem Firmware Update ändern, wenn z.B. zu einem Parameter neue ENUMs herausgefunden werden. Bei den Fehler-Parametern passiert das ab und zu mal. Ohne Firmware Update ändert sich aber nur der Wert. Man könnte ja sagen, dass nach einem Update immer JK=ALL und JK=x ausgeführt werden muss, oder?

@FunkOdyssey: authentifizierung habe ich noch nicht probiert. vielleicht liegt es daran.

die log meldungen sind erst mal nicht kritisch wenn sie nur ab und zu auftreten. wenn du z.b. httpmod gleichzeitig laufen lässt bekommt das modul keine daten wenn die httpmod abfrage gerade läuft. dann wird es beim nächsten mal probiert.

@freez: ich meine mit ändern von einer anfrage zur nächsten.

das sich beim firmware oder sonstigen update etwas ändern kann ist klar. dann kann man von hand ein set getCategories machen und sich alles neue zusammen klicken.

Ok, dann passe ich die Ausgabe entsprechend an, dann sollte JK auch noch schneller gehen.

So, endlich habe ich etwas Zeit und wollte mir das Modul ansehen. Allerdings kommt nach dem "define Broetje_SOB BSB <ip>/passkey/" eine Fehlermeldung:


fhem?detail=Broetje_SOB&fw_id=58 line 86:
TypeError: undefined is not a function (evaluating '$("#BSB_table").treetable({ expandable: true, columnElType: "td,th" })')


Was mache ich falsch? Ich verstehe die Fehlermeldung leider nicht wirklich :(

EDIT: ..oder ist das eine der besagten Fehlermeldungen, die nicht relevant sind..?

nein. die ist nicht zum ignorieren.

wo genau bekommst du diese meldung? mit welchem browser? was sagt die javascript konsole?

Direkt nachdem ich oben in der Zeile bei FHEM das 'define blablabla' eingegeben habe. Browser ist der Raspbian-Hausbrowser, weiß gerade nicht, wie der heißt :(
Äh - sorry - javscript-konsole..?  :o

Falls es hilft, hier ein screenshot..

das ist ein javascript fehler.

hast du die beiden treetable files im richtigen verzeichnis? .../www/pgm2

die js konsole sollte irgendwo in deinem browser zu finden sein.

ARGH - oh man, manchmal bin ich echt zu blöd zum .....  ::)
Ich hatte sie nur in www...  :-[ shame on me..
DANKE!

..ich hatte ja vorgewarnt, ich bin FHEM-n00b..  :-[
Äh - also in der device-Ansicht siehts nun aus wie auf dem screenshot - wie komme ich denn jetzt an die aufklappbare Auswahl..?

Zitat
man kann jetzt entweder das polls attribut von hand setzen, oder in die device detail ansicht gehen und die kategorien aufklappen. sobald für eine kategorie auf die parameter spalte klickt werden die verfügbaren parameter geholt und die betreffende kategorie aufgeklappt.

Btw.: Ich habe FHEM nach dem Kopieren der genannten files einmal neu gestartet. Oder muss ich das Broetje_SOB-device erst einmal löschen und dann neu erstellen?

es schaut so aus als ob das modul die kategorien (noch) nicht geholt hat.

bitte verbose für das device auf 4 setzen. disable auf 1 setzen. disable löschen und ins log schauen.

es sollten die kategorien geholt werden. danach geht das aufklappen.

So, neue Version ist oben - Andre, kannst Du bitte mal schauen, ob für Dich noch alles so läuft, wie es soll? JK=xx geht jetzt auf jeden Fall schneller und könnte von daher auch automatisch in regelmäßigen Abständen durchgeführt werden.

Ok, also im Log steht nun: trying to poll. -> trying to query categories. -> got categories.
Allerdings ist die Ansicht (auch nach Aktualisieren der Seite) die selbe. Keine PullDowns o.ä.  Wenn ich auf "BSB-LAN Web" klicke, komme ich zur entspr. Webseite.
Was mache ich falsch?

zeig mal bitte ein list vom device.

kannst du auch mal einen anderen browser probieren?

Meinst du damit "list Broetje_SOB" oben in der Befehlszeile eingeben? Falls ja: Screenshot im Anhang.

Anderen Browser: Klar, aber da muss ich dann erstmal gucken, welchen schlanken Browser man so bei Raspbian noch installieren kann/sollte.
EDIT: Iceweasel-Installation läuft.. ;)
EDIT2: Auch mit FF-Iceweasel ändert sich nichts :( Leider kommt gleich Besuch, ich mache morgen weiter (wobei ich befürchte, dass ich nicht wirklich weiter komme). Notfalls mache ich nochmal alles platt und installiere einmal komplett neu :( ;)

Also bei mir ist es jetzt auch passiert, dass der Arduino abgeschmiert ist, nach dem Neustart und dem (meiner Erinnerung nach identischen) Wiederholen der Prozedur klappt es jetzt bei mir, d.h., ich kann die Kategorien aufklappen, die ich mit getCategory abrufe und dann z.B. den Parameter 8700 pollen. Es klappte aber auch dann nicht gleich beim ersten Mal, Fehlermeldungen wie

fhemweb.js line 983 > eval line 1:
ReferenceError: BSB_insertParam is not defined

oder (aus der Erinnerung heraus)
${VAR} = ""

Im Moment schaffe ich es auch nicht, mit getCategory eine weitere Kategorie hinzuzufügen. Aber der regelmäßige Abruf von 8700 klappt auf jeden Fall.

Was die Abstürze angeht, bräuchte ich von jemandem nach Möglichkeit einen reproduzierbaren Aufruf, damit ich weiß, welcher der drei Befehle mit ggf. welchen Daten den Absturz hervorruft...

In den Logs habe ich folgende Fehlermeldung gefunden, nach denen die Timeouts, sprich der Absturz, kamen:
PERL WARNING: Use of uninitialized value $dev in pattern match (m//) at ./FHEM/98_BSB.pm line 58.
Vielleicht hilft das?

@Schotty: aus irgend einem grund bekommt das modul keine daten. ich vermute es liegt an der authentifizierung. kannst du es mal bitte ohne probieren?

@freetz: welchen browser verwendest du? ich habe bis jetzt nur mit safari getestet und nur während die detail ansicht offen ist.

hast du die aktuellste version? des moduls? der meldung mit der uninitialized value $dev ist eigentlich schon behoben. du kannst einfach noch einen zusätzlichen parameter im define nach der ip angeben. es ist aber so oder so nur eine warnung die nichts weiter nach sich ziehen sollte.

Firefox auf Mac, Modul von heute Abend, css/js von heute morgen

So, ich glaube, ich habe (einen) Grund für die Abstürze gefunden, denn nicht existierende Parameter oder solche, die CMD_UNKNOWN hinterlegt hatten, sorgten für eine Endlosschleife. In der neuesten Version im master repository ist das jetzt behoben, bitte einmal testen...

Zitat von: freetz am 04 März 2018, 08:50:10
So, ich glaube, ich habe (einen) Grund für die Abstürze gefunden, denn nicht existierende Parameter oder solche, die CMD_UNKNOWN hinterlegt hatten, sorgten für eine Endlosschleife. In der neuesten Version im master repository ist das jetzt behoben, bitte einmal testen...

Das hat wunderbar funktioniert. Ich konnte das BSB-Modul nun auch endlich testen. Danke.-

---

Folgende Erfahrungen habe ich gemacht:

1)
Wenn ich die Authentifizierung fest ins DEF packe, dann funktioniert das sogar. Ist irgendwie quick&dirty, aber bei HTTPMOD war es auch kaum anders. :-)

2)
Ich habe eine Raum, der einen Umlaut im Namen hat. Sobald ich das BSB-Modul im Vordergrund habe, wird scheinbar irgendwie die Codierung der Site geändert und der Umlaut im Raumnamen wird falsch angezeigt.

3)
Ist sicherlich schon bekannt, aber generell werden alle Umlaute im BSB-Modul noch nicht richtig angezeigt.

4)
Das HTML und CSS bei der Categories-Tabelle mit dem Treetable müsste ein wenig überarbeitet werden. Im Dark-Skin scheint es optisch okay zu sein, aber in anderen Skins (z.B. IOS7) ist die "{BSB_getCategories();}" zu weit mittig angeordnet. Nur ein valign="left" reicht hier nicht aus. Es sei denn, man macht die Tabellenzellen schmaler.

5)
Vermutlich ist auch dies noch normal, aber ich war ein wenig irritiert. Ich habe in den BSB-Kategorien keine Expand-Icons. Der einzige klickbare Bereich ist ganz recht bei den IDs (xxxx-xxxx). Aber auch dann wird die Kategorie nicht immer direkt geöffnet. Vermutlich wird hier im Hintergrund nachgeladen. Es funktioniert aber dann nicht, wenn gerade im irgendeine andere Aktion in BSB Web läuft. Dann muss ich die Site neu laden. Dann erscheinen auch die Parameter zur Auswahl.

Ich kann das umgehen, wenn ich die Kategorien manuell vorausfüllen lasse. Mit "set getCategory xx".
Doof nur: Wenn man danach ein "set getCategories" macht, sind alle Expand-Icons wieder verschwunden.
Das Modul merkt sich also scheinbar nicht den Zustand, den man bereits hatte.

6)
Kann man das Default-TimeOut etwas höher als 5sec setzen? Vielleicht sogar das Standard-Intervall? Ich hatte viele viele TimeOut-Error-Readings, da der Arduino gerade bei der Auswahl der Werte und der Kategorien immer ordentlich beschäftigt war. Teilweise hatte ich so viele Parameter abgefragt, dass diese nicht in 5sec abgerufen werden konnten. Höhere Werte würden die ersten Hürden nehmen. Andere User würden sonst den Fehler irgendwo anders suchen. Ich nahm auch erst an, dass Modul oder BSB Web sich an irgendeinem Parameter verschluckt haben. Schlussendlich war es halt nur der TimeOut.

7)
Und dann hatte ich (immer in einem anderen Browser-Tab) die bereits erwähnten JS-Fehler.
Das passiert scheinbar immer dann, wenn man das Modul bzw. BSB Web "beschäftigt" wie bspw. getCategories, getCategory, etc.


Uncaught ReferenceError: BSB_insertParam is not defined
    at eval (eval at FW_doUpdate (fhemweb.js:988), <anonymous>:1:1)
    at WebSocket.FW_doUpdate (fhemweb.js:988)
fhemweb.js:427 10:36:32.355 Rcvd: ["#FHEMWEB:WEB","BSB_insertParam(34,7978,\u0022Fühlertemperatur BX36\u0022,\u0022\u0022);",""]
fhem:1 Uncaught ReferenceError: BSB_insertParam is not defined
    at eval (eval at FW_doUpdate (fhemweb.js:988), <anonymous>:1:1)
    at WebSocket.FW_doUpdate (fhemweb.js:988)
fhemweb.js:427 10:36:32.369 Rcvd: ["#FHEMWEB:WEB","BSB_insertParam(34,7996,\u0022Zustand Kontakt H33\u0022,\u0022\u0022);",""]
fhem:1 Uncaught ReferenceError: BSB_insertParam is not defined
    at eval (eval at FW_doUpdate (fhemweb.js:988), <anonymous>:1:1)
    at WebSocket.FW_doUpdate (fhemweb.js:988)
fhemweb.js:427 10:36:32.381 Rcvd: ["#FHEMWEB:WEB","BSB_insertParam(34,7999,\u0022Eingangssignal H33\u0022,\u0022\u0022);",""]
fhem:1 Uncaught ReferenceError: BSB_insertParam is not defined
    at eval (eval at FW_doUpdate (fhemweb.js:988), <anonymous>:1:1)
    at WebSocket.FW_doUpdate (fhemweb.js:988)


Bitte nicht falsch verstehen. Ich bin total begeistert von diesem Modul. Meine ersten Konfigurationen mit HTTPMOD waren um ein Vielfaches komplizierter. :-)

Zitat von: justme1968 am 03 März 2018, 20:33:35
@Schotty: aus irgend einem grund bekommt das modul keine daten. ich vermute es liegt an der authentifizierung. kannst du es mal bitte ohne probieren?

Du meinst den Passkey hinter der IP? Habe ich probiert, ändert nichts. Ich vermute aber, das Problem sitzt a) tiefer und b) vor dem RPi ;)
Ich habe gestern den Tag damit verbracht, Raspbian&FHEM einmal komplett frisch zu installieren, allerdings kann ich die FHEM-Oberfläche ip:8083 nicht erreichen (arbeite lokal am RPi mit eigenem Monitor, also kein Zugrif via SSH oder so). Ich habe es noch nicht geschafft, dieses Problem zu lösen - kann also u.U. noch dauern, bis ich wieder Rückmeldung geben kann.. :(

Wie ich gerade schon schrieb, geht das mit Authentifizierung und Passkey:

Eintrag im DEF:
user:pass@192.168.0.123/1234

also...

1. ja. authentifizierung hatte ich noch garnicht probiert. kommt.

2. bei mir gehen die umlaute. schaltet der browser automatisch um?

3. auch hier gehen bei mir die umlaute. was genau wird denn angezeigt?

4. ja. ich habe bis jetzt nur mit dark getestet. das alignment gefällt mir überhaupt noch nicht. ich denke ich baue noch eine komplett eigene spalte ein.

5. ist nur das icon nicht sichtbar? oder kannst du auch nicht klicken?
beim klicken rechts auf die ids wird erst dann automatisch ausgeklappt wenn die daten geladen wurden.
das klicken links geht immer wenn die daten da sind. d.h. die kleinen dreiecks icons sind auch nur dann
zu sehen wenn eine kategorie schon mal abgefragt wurde. entweder von hand, oder über das klicken rechts
oder wenn das categories attribut gesetzt ist.

set getCategories setzt im prinzip alles zurück. und ist eigentlich nur nötig wenn eine neue firmware auf das board gespielt wurde. sonst ändert sich ja nichts.

6. der timeout ist nicht fest auf 5 sekunden gestellt sondern hängt davon ab was abgefragt wird.
meine idee ist hier noch die HttpUtils zu ergänzen damit der timeout nicht auf die komplette abfrage gilt sondern immer automatisch zurück gesetzt wird wenn neue daten kommen. dann kann man den timeout weiter recht kurz setzen und merkt wenn das board überhaupt nicht antwortet, so lange aber daten eintröpfeln wird weiter im hintergrund gewartet. das passt besser zum board als ein fester timeout.

7. wie ganz oben schon geschrieben: mehrere tabs sind noch nicht getestet :) das kommt noch.

ich habe eben ganz oben eine neue version hoch geladen bei der die js fehler bei mehreren tabs abgefangen werden.

Zitat von: justme1968 am 05 März 2018, 11:46:25
2. bei mir gehen die umlaute. schaltet der browser automatisch um?

3. auch hier gehen bei mir die umlaute. was genau wird denn angezeigt?

Ähm. Ich wollte das nun rekonstruieren, aber ich schaffe es nun nicht mehr. Das soll nun einmal jemand verstehen. Ich hatte alle Umlaute auf der FHEM-Website und im BSB-Modul fehlerhaft, wenn die Detailseite vom BSB-Modul geöffnet war. Nun ist das nicht mehr so. Also einfach ignorieren. Sorry.

Zitat von: justme1968 am 05 März 2018, 11:46:25
5. ist nur das icon nicht sichtbar? oder kannst du auch nicht klicken?

Das Icon ist nicht vorhanden. Auch nicht im Quelltext.

Zitat von: justme1968 am 05 März 2018, 11:46:25
beim klicken rechts auf die ids wird erst dann automatisch ausgeklappt wenn die daten geladen wurden.

Das kann ich so auch nachvollziehen. Es dauert halt nur sehr lange und man wundert sich, dass nichts passiert. Okay, man muss es halt wissen. Funkioniert wie du es beschrieben hast.

Zitat von: justme1968 am 05 März 2018, 11:46:25
das klicken links geht immer wenn die daten da sind. d.h. die kleinen dreiecks icons sind auch nur dann
zu sehen wenn eine kategorie schon mal abgefragt wurde. entweder von hand, oder über das klicken rechts

Dann ist bei mir ja alles in Ordnung. Es funktioniert so, wie du es beschreibst.
Wobei die Usability ein wenig verwirrend ist - wenn man es denn nicht weiß.
Rechts klicken - warten - erst dann links aufklappen (falls noch nicht auf) - und auswählen.

Zitat von: justme1968 am 05 März 2018, 11:46:25
oder wenn das categories attribut gesetzt ist.

Oh, das kannte ich ja noch gar nicht.

Zitat von: justme1968 am 05 März 2018, 11:46:25
set getCategories setzt im prinzip alles zurück. und ist eigentlich nur nötig wenn eine neue firmware auf das board gespielt wurde. sonst ändert sich ja nichts.

Habe ich bemerkt.

Zitat von: justme1968 am 05 März 2018, 11:46:25
6. der timeout ist nicht fest auf 5 sekunden gestellt sondern hängt davon ab was abgefragt wird.
meine idee ist hier noch die HttpUtils zu ergänzen damit der timeout nicht auf die komplette abfrage gilt sondern immer automatisch zurück gesetzt wird wenn neue daten kommen. dann kann man den timeout weiter recht kurz setzen und merkt wenn das board überhaupt nicht antwortet, so lange aber daten eintröpfeln wird weiter im hintergrund gewartet. das passt besser zum board als ein fester timeout.

Okay

---

Am Rande: Die neue Version läuft gut. Keine JS-Fehler.

So, man solls nicht glauben, aber nach einer erneuten Komplettinstallation kann ich sogar das FHEM-Web wieder erreichen..  ::)

Ich habe das device jetzt wie beschrieben mit den aktuellen Versionen angelegt und kann endlich die Auswahlmenüs/Kategorien für die Parameter sehen *freu*

Bevor ich mich jetzt im Rumspielen verliere - mir ist im Logfile etwas aufgefallen:

PERL WARNING: Use of uninitialized value $dev in pattern match (m//) at ./FHEM/98_BSB.pm line 58.

Ich bin mir allerdings nicht sicher, ob der Eintrag VOR oder NACH der device-Definition entstand..

Eine Minute vorher wurde folgender Log-Eintrag gemacht:

PERL WARNING: Use of uninitialized value $v in concatenation (.) or string at ./FHEM/01_FHEMWEB.pm line 1976.


Bei mir tritt folgender Fehler auf:
Bei Abruf von K37 Diagnose Erzeuger kommt der Ardu in eine Endlosschleife beim ersten error7-Parameter (8009). Nach einem Reset geht das Ganze wieder von vorne los. Abhilfe schafft da nur, wenn ich den FHEM-RPi vom Netz nehme, so dass der Adapter nicht mehr erreichbar ist. Sobald ich den FHEM-RPi wieder ans Netzwerk anschließe, gleiches Verhalten: Anscheinend wird direkt wieder K37 abgerufen - obwohl in der DeviceOverview "category 37 failed" steht und ich keine neue K37- oder sonstige Abfrage gestartet habe.  (Normale K37-Abfrage via BSB-LAN-Webinterface funktioniert (wenn FHEM-RPi nicht im LAN ist).)

So wie ich es verstanden hatte, war das Problem mit der Endlosschleife doch eigtl behoben..?!

Sowohl BSB-LAN als auch Modul-Dateien sind aktuell.

die meldung hatte ich eigentlich schon behoben. da ist beim zusammenbauen der version etwas schief gegangen. hab es noch mal behoben und die version oben aktualisiert.

zur endlosschleife muss freetz was sagen.

@Schotty: Hast du evtl. ein reload 98_BSB.pm vergessen? Oder hattest du FHEM sowieso neu gestartet?

Hatte ich eh neu gestartet, aber ich nehme gleich nochmal die neue .pm und reboote nochmal.
Mich hat nur a) die Endlosschleife gewundert und b) die anscheinend immer neu auftretende Abfrage seitens FHEM.

Ist behoben, das Problem lag in nicht richtig abgefangenen unbekannten Parametern. Ich hoffe, es klappt jetzt...

Ok, soweit funzt es schonmal - super, danke!!

Die Umlaute werden bei mir (standard-'grün/gelbe'-FHEM-Oberfläche mit dem Raspbian-Chromium-Browser) ebenfalls nicht korrekt angezeigt.

bitte zeig mal einen screenshot und ein list.

Zitat von: Schotty am 05 März 2018, 15:01:28
Ok, soweit funzt es schonmal - super, danke!!

Die Umlaute werden bei mir (standard-'grün/gelbe'-FHEM-Oberfläche mit dem Raspbian-Chromium-Browser) ebenfalls nicht korrekt angezeigt.

Im Anhang..

Im Übrigen bekomme ich nur noch time-outs: Wenn ich das device öffne, scheint es einmal initial zu funktionieren, danach nicht mehr. -> EDIT: Laut SerMo-Ausgabe des Ardu werden die Parameter aber erfolgreich abgefragt.

EDIT2: Ich hatte verbose=4 noch nicht gesetzt, habe ich jetzt nachgeholt..

Setze doch mal die das Attribut "Intervall" auf "60" und "Timeout" auf "50". Nur als Versuch.
Das dürfte sich dann mit meiner Beschreibung oben decken.

@justme1968: Schau mal in die Screenshot von Schotty. Der hat auch das Umlaute-Problem.

Hm, hat nichts geändert :(

Doch klar hat sich etwas geändert.
Die Readings wurden aktualisiert (erkennbar an der roten Hervorhebung). Und das Reading lastError ist schon älter. Vorhanden, aber älter. Also liegt kein neuer Fehler vor.

---

Nachtrag 1:

Alle Readings in diesem Modul kann man übrigens wie folgt löschen:
deletereading Broetje_SOB .*

---

Nachtrag 2:
Wen "list vom device" kann man übrigens besser über die Zwischenablage hier im Text-Format einfügen. Besser als ein Sceenshot. Vorzugsweise auch mit CODE-Tags (das # in der Symbolleiste) umrahmen.

---

Nachtrag 3:

Du hast exakt die gleichen Probleme gehabt wie ich. Und wir sollten eigentlich erfahrene BSB-Anwender sein. :-)

Zitat von: FunkOdyssey am 05 März 2018, 15:26:24
Doch klar hat sich etwas geändert.
Die Readings wurden aktualisiert (erkennbar an der roten Hervorhebung).

Ohauahauaha - da siehst du mal, wie man sich täuschen kann.. Für mich war rot = Fehler..  ::) (..und da ich es bisher nur an meinem Heizungsregler-Testsystem laufen habe, ändert sich da ohne mein Zutun auch nichts an den Werten..)
DANKE!

Zitat von: FunkOdyssey am 05 März 2018, 15:26:24
Nachtrag 2:
Wen "list vom device" kann man übrigens besser über die Zwischenablage hier im Text-Format einfügen. Besser als ein Sceenshot. Vorzugsweise auch mit CODE-Tags (das # in der Symbolleiste) umrahmen.

Das stimmt sicherlich - allerdings habe ich den RPi an einem alten Monitor+Tastatur und nicht mittel SSH-Zugriff, da muss ich dann den Umweg über screenshot (oder copy&paste + Editor) und USB-Stick gehen. Keine Ahnung warum, aber irgendwie habe ein besseres 'Gefühl' dabei, wenn ich das nicht via SSH mache, sondern quasi 'direkt' am RPi sitze. Liegt sicherlich an der mangelnden SSH-Erfahrung ;)

Zitat
Du hast exakt die gleichen Probleme gehabt wie ich. Und wir sollten eigentlich erfahrene BSB-Anwender sein. :-)

Wobei ich das -zumindest bei mir- eigtl mehr auf meinen generellen FHEM-noobismus schiebe.. ;)

Ich mach ein List vom Device auch nicht per SSH.
Wenn ich das in FHEM in die Befehlszeile eingebe, so wird mir doch anschließend der Output angezeigt.
Dann markiere ich diesen Text mit der Tastatur oder mit der Maus, kopiere es in die Zwischenablage und füge es dann in ein Post ein. Oder halt dann in eine TXT-Datei.

Ja hast recht - nächstes Mal gibt's das mittels copy&paste -> txt -> usb-stick, ist übersichtlicher - sorry ;) ..oder auch jetzt, falls es noch gewünscht ist..?!

das mit dem tabellen layout habe ich repariert. war eigentlich schon eingebaut, aber nicht ganz richtig :)

es gibt also noch mal eine neue version oben.

das mit den umlauten muss ich mir noch mal in ruhe anschauen. bei mir funktioniert das wie gesagt problemlos.
auf welchem encoding steht dein browser?

ps: list geht aus dem browser und per telnet. ssh ist nicht nötig.

Ok, ich hatte vergessen, dass ich ja auch mit meinem 'normalen' Browser drauf zugreifen kann..  ::)
Im Anhang also nochmal das listing.

Bzgl Browser: Beim RPi-Chromium finde ich die encoding-Einstellung nicht, sollte aber Unicode sein. Beim Firefox definitiv Unicode, habe auch andere Einstellungen getestet, ändert aber nichts (außer leichten Varianten beim Wirrwar).

jetzt noch code tags (das # über den smillies) und alles ist gut :)

das schaut nach korrektem utf8 encoding aus. welches encoding hat dein browser? der sollte ebenfalls utf8 verwenden.

Zitat von: justme1968 am 05 März 2018, 16:33:59
jetzt noch code tags (das # über den smillies) und alles ist gut :)

Das listing war zu lang, irgendwie wurde alles abgeschnitten, habs jetzt angehängt - code-tags hatte ich benutzt ;)

Zitat
das schaut nach korrektem utf8 encoding aus. welches encoding hat dein browser? der sollte ebenfalls utf8 verwenden.

Utf8 steht beim FF leider nicht, nur Unicode. -> google sagt aber, dass das Unicode = UTF8 beim FF ist..

Mit dem 'dark'-style ist übrigens alles gut bzgl. der Umlaute..

hmmm... sehr komisch. der style sollte keinen einfluss auf das encoding haben.

ich schaue es mir an.

Ok, danke!

Hallo, ich habe mal ein wenig mit der HTML-Generierung im Modul rumgespielt, weil ich einfach mal eine Idee vorschlagen wollte.

Als Basis habe ich die letzte Version von justme1968 genommen.

siehe auch 98_BSB.pm im Anhang

Ein alternativer Vorschlag:

danke.

so wie deine erste version sollte es eigentlich aussehen. was ist bei dir anders? hast du wirklich die aktuellste version von oben?

kann gerade deinen code nicht anschauen. mache ich später.

@FunkOdyssey: Zum Vorschlag von gestern, 17:36 (den aktuellen von gerade eben habe ich noch nicht getestet/angesehen): Gefällt mir gut.

Anmerkungen und Fragen -> beziehen sich gerade auf die FunkOdyssey-Version, sind aber z.T. auch allgemeiner Natur:
1. Die beiden Spalten "Category" und "Parameter" könnten schmaler sein, die Spalte "Name" hingegen breiter, so dass im Idealfall alles in eine Zeile passt.
2. Wäre es generell möglich, das Mausicon für die Ladezeit der Kategorien zu verändern (Sanduhr oder so) oder einfach nur einen Hinweis während der Ladezeit einzublenden ("Kategorien werden geladen") oder etwas in der Art? Irgendwie ist es für mich so, dass ich 'unsicher' bin, ob der Mausklick nun ankam/die Kategorien noch geladen werden/die Abfrage bereits beendet ist aber keine Parameter zur Auswahl stehen.
3. Bei etlichen Kategorien erscheinen ja nach dem Laden keine Parameter. Wäre es da möglich, statt der etwaigen Parameter evtl einen Hinweis in der Art einzublenden ('keine auswählbaren Parameter vorhanden') oder so? Dürfte das Ganze etwas übersichtlicher und eindeutiger gestalten.
4. Bei K20 Sitherm Pro (obwohl bei meinem Regler nicht vorhanden) erscheinen Parameter beim Modul, in der Webausgabe allerdings nicht (liegt schätzungsweise an der error7-hide-Funktion). Hat mich nur etwas gewundert, da ich davon ausging, dass diese dann in FHEM auch nicht angezeigt werden.
5. Bei bspw K30 Konfiguration und K33 Wartung kommt zwar die Abfrage durch (laut SerMo), aber es werden keinerlei Parameter im Modul aufgeführt - obwohl da etliche verfügbar sein sollten.
6. Bei bspw. K37 & K38 (Diagnose Erzeuger&Verbraucher) kommt laut SerMo ebenfalls die Abfrage durch, es werden jedoch keinerlei Parameter im Modul angezeigt - stattdessen erscheint ob in FHEM "Connection lost, trying a reconnect every 5 seconds.".
7. Der Link oben "Alle Kategorien laden" funktioniert noch nicht.
8. Die Umlaute werden nun auch im default-style-skin dargestellt.
 

@FunkOdyssey: Zum alternativen Vorschlag 2 -> screenshot: Also die Anzeige der Parameternummern fände ich schon wichtig, die erscheinen bei der aufgeklappten Kategorie dort nicht?!
EDIT: Vergiss es, hatte nicht die große Ansicht, die stehen ja nun rechts..

1. wie breit die spalten sind hängt vom style ab. bei dark sind die spalten nur so breit wie nötig. die anderen styles muss ich mir noch anschauen.

2. am maus icon (oder an einer anderen anzeige) bin ich gerade dran :).

3. ja. ich überlege mir etwas.

4. dazu muss freeze etwas sagen. ich zeige nur an was vom board zurück kommt.

5. + 6. was steht im log? mit verbose 4 und danach mit 5 schauen.

7. welchen link meinst du ?

Bezog sich auf das Design-Beispiel von FunkOdyssey von gestern. Nachdem ich mir das Logfile angesehen und danach die Device-Ansicht neu geöffnet habe, hat sich allerdings merkwürdigerweise einiges geändert und machen einige Punkte meiner obigen Aufzählung hinfällig:
- Umlaute werden nun NICHT mehr korrekt dargestellt (default-style-skin)?!
- Punkt 4,5,6 sind hinfällig, nun wird alles angezeigt?!
- ich meinte den Link bei FunkOdysseys geändertem Beispiel: Oben bei "Funktionen:", rechts neben "Öffne BSB-LAN Web" steht nun noch "Alle Kategorien laden", der Link funzt allerdings noch nicht.

Zitat von: justme1968 am 06 März 2018, 11:16:31
so wie deine erste version sollte es eigentlich aussehen. was ist bei dir anders? hast du wirklich die aktuellste version von oben?
kann gerade deinen code nicht anschauen. mache ich später.

Das ist wirklich deine neueste Version. Im Markup habe ich aber ein paar Dinge geändert.

Zitat von: Schotty am 06 März 2018, 11:31:46
@FunkOdyssey: Zum alternativen Vorschlag 2 -> screenshot: Also die Anzeige der Parameternummern fände ich schon wichtig, die erscheinen bei der aufgeklappten Kategorie dort nicht?!
EDIT: Vergiss es, hatte nicht die große Ansicht, die stehen ja nun rechts..

Den zweiten Vorschlag hatte ich erstellt, da bei der vierspaltigen Variante zu 90% eine Spalte ja immer leer ist. Daher habe ich das auf drei Spalten eingestampft und die Range wie die IDs in einer Spalte aufgenommen.

Tipp:
Ich habe mit LABELs gearbeitet, so dass man nun nicht nur die Checkbox anklicken kann, sondern auch die IDs. In der Variante Nr. 2 kann man auch auf die Bezeichnung klicken und die Checkbox wird umgeschaltet.

Zitat von: justme1968 am 06 März 2018, 11:35:20
1. wie breit die spalten sind hängt vom style ab. bei dark sind die spalten nur so breit wie nötig. die anderen styles muss ich mir noch anschauen.

Das ist immer wieder das Problem. Ich wollte sogar eigentlich mit alternierenden Spalten arbeiten. Doch dann hätte ich die Farbwerte fest im Code oder ins TreeTable-CSS packen müssen. Das mag dann beim Dark-Skin nicht mehr so hübsch aussehen.

Generell habe ich alle Tabellen auf 100%. Und die meisten Skins floaten auch auf 100% Breite. Ich weiß, dass Matthias Kleine mit seinem Hausautomatisierungs-Skin es etwas anders macht. Der nutzte fixe Breiten.

Das TreeTable mit 100% Breite wäre konsistent (siehe Vorschlag 1), aber wenn man im Attribut "poll" erst einmal ne ordentliche Liste an IDs aufgenommen hat, so wird die Tabelle insgesamt sehr breit und damit auch die Spalten (im Vorschlag Nr. 1 je 25%). Im Vorschlag Nr. 2 habe ich einfach 40% Breite angenommen. Das lässt die Werte näher aneinander rücken. Auch von Vorteil bei breiten Monitoren. Nun ja. Viele Wege führen nach Rom.

Zitat von: justme1968 am 06 März 2018, 11:35:20
2. am maus icon (oder an einer anderen anzeige) bin ich gerade dran :).

Das wäre wirklich hilfreich.

Zitat von: justme1968 am 06 März 2018, 11:35:20
7. welchen link meinst du ?

Der meinte vermutlich meine Version (Variante Nr.1). Dort habe ich den JS-Link zu getCategories() nach oben geholt.
Vorher war dieser mit dem Titel verlinkt. Klickt man dort versehentlich drauf, so gehen alle geladenen Parameter wieder verloren. Das fand ich extrem störend.

---

Ich habe die Variante 2 nun auch hochgeladen. Siehe Post mit dem Screenshot.

das mit den labels habe ich extra nicht gemacht da später noch mehr spalten mit checkboxen für die unterschiedlichen intervalle dazu kommen sollen. dann funktioniert das mit dem anklicken des labels nicht mehr sinnvoll.

vielleicht ist es wichtig noch mal die genauen szenarien und bedienung durchzugehen.

zur tabelle allgemein. ich glaube es wird problematisch eine lösung zu finden die mit allen styles funktioniert. ausser man baut wirklich etwas in alle styles ein. aber: das man die am ende nur noch beim einrichten des moduls verwendet und danach eher nicht mehr. d.h. sie muss zwar gut und mit allen themes zu bedienen sein und es darf keine unsicherheit bezüglich wartezeiten geben, sie muss aber auch nicht perfekt aussehen da sie nicht als status anzeige verwendet wird.

das alle geladenen parameter verloren gehen ist eher gut als schlecht. der anwendungsfall für das laden aller kategorien ist ja eher das sich an der firmware etwas geändert hat. d.h. es haben sich eventuell auch die parameter geändert. wenn die alten erhalten bleiben gibt es ein mischmasch aus alt und neu.

das problem mit den umlauten verstehe ich aktuell noch überhaupt nicht.

ansonsten: schön das ihr so fleissig testet und vorschläge macht.

Zitat von: justme1968 am 06 März 2018, 12:00:10
das problem mit den umlauten verstehe ich aktuell noch überhaupt nicht.

ansonsten: schön das ihr so fleissig testet und vorschläge macht.

..das mit den Umlauten verstehe ICH erst recht nicht - zumal es vorhin beim ersten Aufruf korrekt im default-skin dargestellt wurde, danach aber dann plötzlich nicht mehr. Ich habe jetzt zwar auch auf den dark-skin gewechselt, versuche aber zumindest im Rahmen meiner Möglichkeiten einigermaßen viele Varianten / Szenarien zu testen.

Schön, dass du/ihr so fleißig entwickelt! ;)

Ich hätte da mal eine kurze OT-Frage:
Ist es möglich, den einzelnen Parameter-Readings von EINEM Modul-Device unterschiedliche Icons zuzuweisen? Ich habe schon gesucht, aber irgendwie bezieht sich das immer auf einzelne Devices. Oder müsste ich dann beim Modul auch für die jeweiligen Readings (bspw Kesseltemp, TWW-Temp, Stati) jeweils ein extra-device anlegen?

icons gehören immer zum device. nicht zu einem reading.

je nach dem was du machen möchtest: schau dir readingsProxy oder readingsGroup an.

beispiele für beides gibt es im wiki.

Super, danke!

Zitat von: justme1968 am 06 März 2018, 12:00:10
das problem mit den umlauten verstehe ich aktuell noch überhaupt nicht.

Nur zur Info: Aktuell tritt das Problem plötzlich auch beim dark-skin auf (Modul-Variante: FunkOdyssey von gestern Abd), s. screenshot..

bitte schau mal im browser welches encoding er gerade verwendet/erkannt hat.

was passiert wenn du das encoding im browser von hand umstellst?

Das selbe encoding wie auch vorhin und gestern: Unicode, also UTF-8 in Firefox.
Wenn ich es manuell auf bspw 'Westlich' stelle, siehts noch wilder aus, s. screenshot. Dann zurück auf 'Unicode' ist es so wie beim screenshot im vorherigen Beitrag.

Ich kann es scheinbar endlich nachstellen.
Bei mir werden die (eigentlich UTF8)-Umlaute als ISO8859-Zeichen dargestellt, sobald ich die Parameter einer Kategorie geladen habe, in denen Umlaut enthalten sind.

Vorgehensweise:
- "Reset" per getCategories
- Klick auf Kategorie Nr. 37 "Diagnose Erzeuger"
- Nachdem diese geladen wurden (und - bei mir - ein Reload der Site), sind Parameter wie bspw. "Kesselrücklauftemperatur Ist" gelistet.
- Und prompt ändert sich die Anzeige aller Umlaute.

Evtl. ein doppeltes "latin1ToUtf8()"? Nö, das war es, glaube ich, nicht.

Zitat von: FunkOdyssey am 06 März 2018, 14:45:24
Vorgehensweise:
- "Reset" per getCategories

Würde ich gerne nachstellen, aber was meinst du damit? Da steht doch nur 'set'?

Das meine ich damit. Dadurch werden ja alle Parameter im Baum wieder gelöscht.
Ich will damit nur bezwecken, dass wir die gleiche Ausgangssituation haben.

Schon klar, daher meine Nachfrage. Also ich habe es nachgestellt, und die Umlaute werden nicht korrekt angezeigt.

Ich habe danach mal ein "shutdown restart" von FHEM ausgeführt, dann das device geöffnet und die Umlaute sind korrekt. Dann auf K37 geklickt - 'connection lost'-Meldung erhalten, K37 war nicht verfügbar, laut Log kam aber die Rückmeldung korrekt an (Kategoriewerte wurden dort aufgeführt). Dann ein reload der Seite und nun waren die Umlaute falsch, dafür aber K37 verfügbar.

bitte mach mal die js konsole auf bevor die 'connection lost' meldung kommt und schau danach ob dort mehr zu sehen ist.

eventuell kommt in den daten die per longpoll zum browser geschickt werden noch ein zeichen vor das noch anders kodiert oder escaped werden muss.

fhemweb.js:427 15:05:15.803 FW_queryValue:{ReadingsVal("bsb","getCategories","")}
fhemweb.js:427 15:05:15.806 FW_queryValue:{AttrVal("bsb","room","")}
fhemweb.js:427 15:05:15.904 Inform-channel opened (websocket) with filter bsb
fhemweb.js:427 15:05:16.003 Rcvd: ["bsb","connected","<div id=\u0022bsb\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</div>"]
fhem?detail=bsb&fw_id=:402 15:05:25.744 FW_cmd:/fhem?cmd=set bsb getCategory -silent 37&XHR=1
fhemweb.js:427 15:05:33.519 Rcvd: ["bsb","connected","<div id=\u0022bsb\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</div>"]
fhemweb.js:427 15:05:33.519 Rcvd: ["bsb-Aussentemperatur","9.7","9.7"]
fhemweb.js:427 15:05:33.519 Rcvd: ["bsb-Aussentemperatur-ts","2018-03-06 15:05:33","2018-03-06 15:05:33"]
fhemweb.js:427 15:05:38.263 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
VM1720:1 15:05:43.164 ERRMSG:<
fhemweb.js:427 15:05:43.264 Inform-channel opened (websocket) with filter bsb
fhemweb.js:427 15:05:43.513 Rcvd:
fhemweb.js:427 15:05:56.050 Rcvd: ["bsb","connected","<div id=\u0022bsb\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</div>"]
fhemweb.js:427 15:05:56.050 Rcvd: ["bsb-Aussentemperatur","9.8","9.8"]
fhemweb.js:427 15:05:56.050 Rcvd: ["bsb-Aussentemperatur-ts","2018-03-06 15:05:56","2018-03-06 15:05:56"]
fhemweb.js:427 15:05:56.051 Rcvd: ["bsb-Kesseltemperatur","30.5","30.5"]
fhemweb.js:427 15:05:56.052 Rcvd: ["bsb-Kesseltemperatur-ts","2018-03-06 15:05:56","2018-03-06 15:05:56"]

Zitat von: justme1968 am 06 März 2018, 15:04:06
eventuell kommt in den daten die per longpoll zum browser geschickt werden noch ein zeichen vor das noch anders kodiert oder escaped werden muss.

Das erinnert mich ein wenig ans Byte-order mark (BOM), welches auch gerne mal HTML-Templates "zerstört". :-)


15:07:20.510 FW_cmd:/fhem?cmd=set Broetje_SOB getCategory -silent 38&XHR=1
fhemweb.js:427:5
15:07:25.581 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:427:5
15:07:30.486 ERRMSG:<
fhemweb.js:427:5
15:07:30.585 Inform-channel opened (HTTP) with filter Broetje_SOB
fhemweb.js:427:5
15:07:30.609 Rcvd:
fhemweb.js:427:5
15:07:32.889 Rcvd: ["Broetje_SOB","connected","<div id=\u0022Broetje_SOB\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</div>"]
fhemweb.js:427:5

Der erste Eintrag war der Klick auf K38, der zweite Eintrag kam dann mit der Fehlermeldung.

Nur am Rande, da ich gerade wieder über die GoogleChome<>Longpoll-Threads (Beispiel (https://forum.fhem.de/index.php/topic,85080.0)) gestolpert bin:
Obwohl ich primär den Chrome nutze; der Codierungsfehler tritt auch im Firefox-Browser auf.

Oh, hatte ich das nicht erwähnt? Bei mir isses auch der aktuelle Firefox, yo..

..ich hatte irgendwo etwas bzgl einer Angabe

<meta charset="utf-8">

gelesen, kenne mich da aber ja auch nicht so aus.. ;)

im ersten beitrag ganz oben gibt es ein update bei den das encoding problem repariert sein müßte. der longpoll abbruch sollte damit auch behoben sein.

bitte nur mit einer aktuellen HttpUtils version (heute aus dem svn oder morgen im update) testen. da ist der oben erwähnte patch für den incrementellen timeout drin. d.h. so lange das board sendet werden die daten empfangen ohne den timeout hoch drehen zu müssen.


mit der aktellen firmware ist die abfrage der kategorien und parameter bei mir übrigens so schnell das auch das lange warten zwischen anklicken und aufklappen weg sein sollte. kategorie 37 (ich glaube das ist mit die längste) braucht keine 4 sekunden mehr.

eine vorläufige busy anzeige ist auch drin.

die richtige busy anzeige und eine anzeige für nicht vorhandene daten kommt im nächsten update.

die vorschlage zum layout und style muss ich mir noch anschauen.

Kurz und knackig: Läuft gut! Danke.

@justme1968: Klasse, bisher ist alles fein! :)
Umlaute sind korrekt beim aktuellen Firefox, busy-Anzeige gefällt mir gut; lediglich ein Schönheitsfehler ist mir gerade aufgefallen: Bei einer aufgeklappten Kategorie sind Parameternummer und -name nicht mehr so richtig auf einer Zeilenhöhe, s. screenshots.

@justme1968:
Ich will keineswegs nerven oder Stress machen. Aber ich könnte anfangen, das Modul produktiv zu nutzen, wenn die Namen der Readings FHEM-konform wären.
Dies steht bereits auf deiner ToDo-Liste.
Ich habe es nicht eilig, aber das wäre für mich noch ein Showstopper. Die restlichen Features sind eher unkritisch.

Gibt es ne Chance, diesen Punkt vorzuziehen? Danke.

im prinzip ja. aber ich habe noch keine idee wie man das wirklich gut automatisch machen kann so das auch 'schöne' namen dabei heraus kommen.

das beste was ich bis jetzt habe ist etwas das man dann noch von hand per attribut verbessern kann.

wenn dir das gut genug ist würde ich am wochenende eine version damit hochladen. 

Wow, das wundert mich jetzt. Ich dachte, dass man das mit nem regulären Ausdruck relativ einfach umschreiben könnte. Vermutlich habe ich aber die Komplexität bzw. die Vielfalt der Bezeichnungen unterschätzt. Wenn du das schon nicht weiß, wie das gehen soll, dann werde ich dir sicherlich auch nicht helfen können. :-)

das wie ist nicht das problem...
umlaute durch die zwei buchstaben version ersetzen, alle anderen nicht erlaubten zeichen streichen. das problem ist: dabei kommen nicht nur 'schöne' namen raus und manchmal ist ein bindestrich besser als das leerzeichen zu entfernen, manchmal ist das entfernen besser. dieser teil lässt halt sich nicht automatisieren.

aber wie gesagt: wenn dir die automatischen namen reichen ist es kein problem.

im ersten beitrag gibt es ein update mit dem die reading namen jetzt fhem-konform sein sollten.

@Schotty: das mit zeilenhöhe kann weder mit safari noch mit firefox auf einem mac reproduzieren. passiert das immer?

..ich würd's ja gerne testen und wollte es auch gerade tun, aber seit ich eben ein Update beim RPi und danach ein 'update all' bei FHEM gemacht habe, startet a) FHEM nicht mehr automatisch beim RPi-Boot oder stoppt sehr schnell und b) stoppt FHEM bereits nach kurzer Zeit, wenn ich es manuell starte. Keine Ahnung was das ist, muss ich mal googeln. Momentan sitze ich aber gerade an der Aktualisierung des Handbuchs, kann also dauern, bis ich den Fehler bei FHEM gefunden habe.. :(

@justme1968: Nachtrag zum Absturzproblem:
Im FHEM-Log steht als letzter Eintrag Folgendes:
Undefined subroutine &main::decode called at ./FHEM/98_BSB.pm line 555.
Wenn ich neu starte, liest er anscheinend auch noch korrekt die bereits im BSB-LAN-Modul definierten Parameter aus, stoppt FHEM aber dann und im Log steht wieder die genannte Zeile.
Ich habe die aktuelle Modul-Version in Verwendung, also die, die du gerade hochgeladen hast. Liegt das Stoppen also an einem Fehler im Modul?

sorry. da hatte noch ein import gefehlt. habs repariert und die version ganz oben aktualisiert.

Aah ja, jetzt läufts - super, danke.
Also das mit dem Versatz in den Zeilen bei aufgeklappter Kategorie passiert noch immer. Anbei mal zwei screenshots mit dem dark-skin. Der erste screenshot ist vom Firefox, der zweite vom Chrome (beide unter Ubuntu).

Guten Morgen,

gestern Abend habe ich das Modul bei mir installiert und in Betrieb genommen. Das funktionierte soweit ohne probleme. Die Kategorien wurden auch eingelesen.
dann als ich die Kategorien angeklickt habe zeigte es mir aber nicht die Parameter (kein aufklappen) an. Ich hatte dabei die fast aktuelle Version auf dem Arduino.
diesen habe ich dann upgedatet und das Device gelöscht und wieder neu definiert. Das Ergebnis blieb allerdings genauso.
Habe ich da noch etwas vergessen, oder falsch gemacht ?

Jens

Moin Jens,
du musst zuerst rechts auf die Nummernbereiche (xxx-yyy) klicken, dann lädt er die Kategorien, danach kannst du sie aufklappen. Bei den screenshots in meinem vorherigen Beitrag kann man es auch gut sehen.
Gruß

Zitat von: Schotty am 19 März 2018, 09:51:09
Moin Jens,
du musst zuerst rechts auf die Nummernbereiche (xxx-yyy) klicken, dann lädt er die Kategorien, danach kannst du sie aufklappen. Bei den screenshots in meinem vorherigen Beitrag kann man es auch gut sehen.
Gruß

Ja, so hatte ich es auch verstanden, nur habe ich die Kategorien nicht?
Und mit set BSB getCategories kommt auch nichts.
(https://uploads.tapatalk-cdn.com/20180319/24892938b4178d99cbe40c81f5e2cb5a.jpg)

Gesendet von meinem F5121 mit Tapatalk

Was sagt die verbose5-Ausgabe?

Hmm, ich kanns gerade nicht im live-Betrieb testen..
Da du vorher geschrieben hattest, dass die Kategorien auch eingelesen werden und nur nicht aufgeklappt werden können, dachte ich, es wäre das erwähnte Klicken auf die Zahlenbereiche :( Aber nun scheinen ja die gesamten Kategorien gar nicht eingelesen zu werden..
Also alles aktuelle Versionen? Hast du mal ein FHEM-Update gemacht? Andre hatte mal was bzgl einer nötigen aktuellen HttpUtils-Version geschrieben, aber das bezog sich auf die timeouts. Passkey etc wirst du ja auch nicht gesetzt haben, verbunden wird ja auch angezeigt.. grübel..
Sorry, leider keine Ahnung :( :(

Zitat von: FunkOdyssey am 19 März 2018, 11:31:54
Was sagt die verbose5-Ausgabe?


2018.03.19 18:47:32 4: BSB: trying to poll.
2018.03.19 18:47:40 4: BSB: trying to query categories.
2018.03.19 18:47:40 5: BSB: received

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html><head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <title>BSB-LAN Web</title> <link rel="shortcut icon" type="image/x-icon" href="http://arduino.cc/en/favicon.png" /> <style>A:link {color:blue;text-decoration: none;} A:visited {color:blue;text-decoration: none;} A:hover {color:red;text-decoration: none;background-color:yellow} A:active {color:blue;text-decoration: none;} A:focus {color:red;text-decoration: none;} input {width: 100%; box-sizing: border-box;} select {width: 100%;}</style> </head><body> <script>function set(line,formnr){ if(isNaN(document.getElementById('value'+formnr).value)==false){ window.open('S'+line+'='+document.getElementById('value'+formnr).value,'_self'); }} function setbit(line,formnr){ var x=document.getElementById('value'+formnr); var value=0; for (var i=0; i<x.options.length; i++) { if(x.options[i].selected){ value=value+eval(x.options[i].value); }} window.open('S'+line+'='+value,'_self'); }</script> <font face='Arial'> <center><h1><A HREF='/2201/'>BSB-LAN Web</A></h1></center> <table width=80% align=center><tr bgcolor=#f0f0f0><td width=20% align=center><a href='/2201/K'>Heizungsfunktionen</a></td><td width=20% align=center><font color=#000000>DS18B20-Sensoren</font></td><td width=20% align=center><font color=#000000>DHT22-Sensoren</font></td><td width=20% align=center><a href='/2201/DG'>Anzeige Logdatei</a></td></tr><tr bgcolor=#f0f0f0><td width=20% align=center><a href='/2201/C'>Konfiguration</a></td><td width=20% align=center><a href='/2201/O'>URL-Befehle</a></td><td width=20% align=center><a href='http://github.com/fredlcore/bsb_lan/blob/master/HOWTO_de.md' target='new'>HowTo</a></td><td width=20% align=center><a href='http://github.com/fredlcore/bsb_lan/blob/master/FAQ_de.md' target='_new'>FAQ</a></td> </tr></table><p></p><table align=center width=80%><tr><td> </td></tr></table> </body> </html>
2018.03.19 18:47:40 4: BSB: got categories.
2018.03.19 18:47:40 5: $VAR1 = {};
2018.03.19 18:47:45 4: BSB: trying to poll.
2018.03.19 18:48:02 4: BSB: trying to poll.
2018.03.19 18:48:15 4: BSB: trying to poll.
jump to the top


dein  board liefert keine werte:2018.03.19 18:47:40 5: $VAR1 = {};

welche sketch version hast du drauf?

was bekommst du wenn du im browser http://<ip>/JK=ALL aufrufst?

Zitat von: justme1968 am 19 März 2018, 19:04:07
welche sketch version hast du drauf?

Version 0.41 gestern abend runtergeladen

Zitat
was bekommst du wenn du im browser http://<ip>/JK=ALL aufrufst?

Mit Passwort geht schon, oder ? -> DEF    192.168.6.23/xxxx/

{
"0": { "name": "Uhrzeit und Datum", "min": 0, "max": 6 },
"1": { "name": "Bedieneinheit", "min": 20, "max": 70 },
"2": { "name": "Funk", "min": 120, "max": 140 },
"3": { "name": "Zeitprogramm Heizkreis 1", "min": 500, "max": 516 },
"4": { "name": "Zeitprogramm Heizkreis 2", "min": 520, "max": 536 },
"5": { "name": "Zeitprogramm 3/HKP", "min": 540, "max": 556 },
"6": { "name": "Zeitprogramm 4", "min": 560, "max": 576 },
"7": { "name": "Zeitprogramm 5", "min": 600, "max": 616 },
"8": { "name": "Ferien Heizkreis 1", "min": 632, "max": 648 },
"9": { "name": "Ferien Heizkreis 2", "min": 649, "max": 665 },
"10": { "name": "Ferien Heizkreis P", "min": 666, "max": 682 },
"11": { "name": "Heizkreis 1", "min": 700, "max": 900 },
"12": { "name": "Kühlkreis 1", "min": 901, "max": 969 },
"13": { "name": "Heizkreis 2", "min": 1000, "max": 1200 },
"14": { "name": "Heizkreis 3/P", "min": 1300, "max": 1500 },
"15": { "name": "Trinkwasser", "min": 1600, "max": 1680 },
"16": { "name": "Hx-Pumpe", "min": 2008, "max": 2051 },
"17": { "name": "Schwimmbad", "min": 2055, "max": 2080 },
"18": { "name": "Vorregler/Zubringerpumpe", "min": 2110, "max": 2150 },
"19": { "name": "Kessel", "min": 2200, "max": 2551 },
"20": { "name": "Sitherm Pro", "min": 2700, "max": 2732 },
"21": { "name": "Wärmepumpe", "min": 2785, "max": 3010 },
"22": { "name": "Energiezähler", "min": 3095, "max": 3267 },
"23": { "name": "Kaskade", "min": 3510, "max": 3590 },
"24": { "name": "Zusatzerzeuger", "min": 3700, "max": 3723 },
"25": { "name": "Solar", "min": 3810, "max": 3887 },
"26": { "name": "Feststoffkessel", "min": 4102, "max": 4141 },
"27": { "name": "Pufferspeicher", "min": 4708, "max": 4813 },
"28": { "name": "Trinkwasserspeicher", "min": 5010, "max": 5131 },
"29": { "name": "Trinkwasser Durchl'erhitzer", "min": 5400, "max": 5544 },
"30": { "name": "Konfiguration", "min": 5700, "max": 6421 },
"31": { "name": "LPB-System", "min": 6600, "max": 6650 },
"32": { "name": "Fehler", "min": 6705, "max": 6846 },
"33": { "name": "Wartung/Sonderbetrieb", "min": 7001, "max": 7254 },
"34": { "name": "Ein-/Ausgangstest", "min": 7700, "max": 7999 },
"35": { "name": "Status", "min": 8000, "max": 8099 },
"36": { "name": "Diagnose Kaskade", "min": 8100, "max": 8150 },
"37": { "name": "Diagnose Erzeuger", "min": 8300, "max": 8570 },
"38": { "name": "Diagnose Verbraucher", "min": 8700, "max": 9075 },
"39": { "name": "Feuerungsautomat", "min": 9500, "max": 9627 },
"40": { "name": "Benutzerdefiniert", "min": 10000, "max": 10000 },
"41": { "name": "PPS-Bus", "min": 10500, "max": 10515 }
}


Hallo,

nachdem ich heute Abend das device nochmals gelöscht habe funktioniert es. Ansonsten habe ich nichts verändert.
Bei der Namesgebung der Parameter istmir aufgefallen, dass wenn z.B. Parameter des HK1 und HK2 ausgewählt werden sind die Namen doppelt und es wird nur ein Heizkreis angezeigt.

z.B.     700,710,900,1000,1010,1200

Ansonten schaut´s gut aus. Tolle Arbeit.

Jens

was meinst du mit namen doppelt und nur ein heizkreis angezeigt?

Zitat von: justme1968 am 20 März 2018, 06:48:01
was meinst du mit namen doppelt und nur ein heizkreis angezeigt?

Ja, das meinte ich, weil die Namen der Readings sich dann doppeln.

Ja, das passiert, weil sich in der Webansicht die Info über den Heizkreis schon aus der Kategorie ergibt. Da steht also
700 - Heizkreis 1 - Betriebsart
und nicht
... Betriebsart HK1
Da sich alle Parameter in 700//900/1200 etc. vom Namen her doppeln, müssten sonst alle Parameter entsprechend im Namen erweitert werden, was wiederum möglicherweise bestehende HTTPMOD regex brechen könnte (wenn jemand z.B. ohne Wildcards arbeitet). Die andere Alternative wäre, immer die Kategorie im Reading voran zu stellen, oder zumindest die Parameternummer, um Verwechslungen zu vermeiden.

Eine andere Frage: Isr die JSON Struktur für's Senden und Auslesen jetzt soweit in Ordnung, dass ich sie abhaken kann? Ich schulde Schotty noch die entsprechende Dokumentation für's Handbuch und wollte die erst machen, wenn sich da nix mehr ändert...

arg... ich habe nur einen heizkreis. deshalb ist mir das noch nicht aufgefallen. ich muss mal überlegen wie ich das noch in die readings namen bekomme. an der stelle habe ich die information aktuell garnicht mehr.

viel schöner wäre es wenn das im json direkt mit enthalten wäre. entweder im namen, oder als zusätzlicher knoten. {..., "hk" = "x", ... }.

habe gerade gesehen das es auch noch andere kategorien betrifft. ich habe z.b. noch zeitprogramm 4 und zeitprogramm 5. die Bezeichnungen für die heizkreise sind auch nicht einheitlich. mal 3, mal 3/HKP und mal 3/P.

das automatisch zu parsen wird vermutlich unzuverlässig. erst recht wenn es wirklich universell sein soll.

siehst du eine möglichkeit das irgendwie noch im json unterzubringen? muss auch nicht bei den parametern sein. bei den kategorien würde reichen. z.b. ein "suffix" = "..." knoten.  da könnte dann HKx rein oder eine laufende nummer. je nach kategorie.

dann könnte man sogar den teil aus dem namen weg lassen. und über all mit dem suffix knoten arbeiten wenn der name nicht eindeutig ist. damit könnte man sogar die diagnose parameter automatisch einem heizkreis zuordnen. da steckt ja alles in einer kategorie und der hk ist teil des namens. aber zum teil mit anderen abkürzungen. auch zum teil zwischen den einzelnen parametern. mal nur eine zahl, mal als Hx.

ich weiss das klingt nach einer größeren änderung... aber es wäre um einiges flexibler, zuverlässiger und zukunftssicherer.

wenn wir für dieses problem eine lösung haben müsste das auslesen erledigt sein.


das senden habe ich bisher nur überflogen und noch nicht getestet. das wollte ich dann als nächstes angehen. hatte die letzten wochen nicht genug zeit.

Abgesehen von der Zeit, die ich dafür zumindest im Moment nicht habe (der Frühling kommt, und das Robotan-Rasennmähroboter-Projekt zieht wieder (auch zu viel) Zeit), müsste ich ja auch in der BSB-LAN-Software für jeden der Parameter noch irgendwo die Info hinterlegen, ob es HK1, Zeitprogramm 5 oder sonst was ist. Zumindest dann, wenn es eben ein anderer Text als nur der Kategoriename sein soll. Den könnte ich relativ einfach auch noch mal in der Parameterabfrage hinterlegen. Andernfalls bedeutet ein einzelnes Byte, was ich in die Command-Table aufnehme, einen zusätzlichen Speicherverbrauch von ca. 3kB. Das hört sich nicht nach viel an, für den Arduino mit seinem geringen Speicher macht das aber schon einen Unterschied.

Was spräche denn dagegen, das Reading in der Form "Kategoriename_Parametername" zu benennen? Oder (wahlweise?) "Parameternummer_Parametername"? Die erste Variante wäre zwar etwas länger, aber so lang dann auch wieder nicht und wäre auch hinsichtlich der z.T. ja schon umgesetzten Mehrsprachigkeit die universellere Lösung.

Dann warte ich mit der Dokumentation noch, bis wir die Dinge und das Senden geklärt haben (auch wenn Schotty das nicht freuen wird ;) )...

Zitat von: freetz am 20 März 2018, 09:29:24
Was spräche denn dagegen, das Reading in der Form "Kategoriename_Parametername" zu benennen? Oder (wahlweise?) "Parameternummer_Parametername"? Die erste Variante wäre zwar etwas länger, aber so lang dann auch wieder nicht und wäre auch hinsichtlich der z.T. ja schon umgesetzten Mehrsprachigkeit die universellere Lösung.

Also Parameternummer_Parametername finde ich persönlich besser, das ist eine eindeutige Bezeichnung, die auch in den Handbüchern verwendet wird und bei Komplettabfragen nützlich sein dürfte - dann sucht man fix nach der Nummer und fertig. Die Darstellung der Readings dann auch aufsteigend den Nummern nach, schon ists übersichtlich..! Just my 50ct.. ;)
Parameternummer_Kategoriename_Parametername wäre natürlich noch besser, aber wahrscheinlich zu lang? Oder könnte man die Readings in die jeweiligen Kategorien gruppieren? Und dann mit Nr+Name in der Kategoriegruppe anzeigen? 

Zitat
Dann warte ich mit der Dokumentation noch, bis wir die Dinge und das Senden geklärt haben (auch wenn Schotty das nicht freuen wird ;) )...

Alles gut, ich hab das erstmal auf Eis gelegt bis die JSON-Geschichte abgeschlossen ist - vorher gibts auch keine neue Handbuch-Version, um Verwirrungen zu vermeiden ;)

Jetzt, wo Du es so sagst, finde ich Parameternummer_Parametername auch sinnvoll(er), denn auch die Parameternamen unterscheiden sich mitunter etwas, so dass die Leute bei Nachfragen dann eindeutiger angeben können, um was es geht. Wenn man das noch optional macht, könnten auch Leute, denen es egal ist und wir wir nur einen Heizkreis etc. haben, die Nummern auch weglassen, wenn es der Optik auf dem Floorplan oder so entgegen steht.

ja. so ist es natürlich ganz einfach. im ersten post gibt es ein update mit dem neuen attribut readingsFormat.

1 -> nummer-name
2 -> nur nummer
3 -> nur name

1 ist der default. ich habe noch führende nullen spendiert wenn die nummer weniger als 4 stellen hat. sonst ist es mit der ordnung wieder nichts :).

das einzige das damit nicht geht ist automatisch zusammengehörige dinge zu erkennen wie weiter oben vorgeschlagen. aber das kann man ja immer noch machen wenn zeit ist und es benötigt wird.


readings gruppieren geht leider nicht. aber irgendwann mache ich das readingsFormat vielleicht noch etwas flexibler damit man selber angeben kann wie es genau aussehen soll. z.b. %k_%p-%n für kategorie_parameter-name.

Na das klingt doch gut!
Wobei ich das:

Zitat von: justme1968 am 20 März 2018, 11:31:24
das einzige das damit nicht geht ist automatisch zusammengehörige dinge zu erkennen wie weiter oben vorgeschlagen. aber das kann man ja immer noch machen wenn zeit ist und es benötigt wird.

nicht so ganz verstehe - was meinst du damit?
Ansonsten - nur mal so gaaaaanz vorsichtig nachgefragt - die 'Wünsche' ganz am Anfang, von wegen click&play für noobs hinsichtlich zu loggender Parameter, Fehler-/Warnmitteilungen-Push etc.pp.wird man mit FHEM-Mitteln direkt umsetzen müssen? Oder bastelst du da im Laufe der Zeit noch was..? ;) Dann warte ich nämlich noch mit dem Einrichten (mir fehlt echt die Zeit für FHEM-Kenntnisse grrrr)..  ;D

als informatiker ist es immer schön wenn man bestimmte semantische information nicht aus irgendwelchen textuellen beschreibungen wie zum beispiel den namen extrahieren muss, sondern sie schon fertig aufbereitet und eindeutig bekommt. eine art 'tag' um z.b. den hk eindeutig zu erkennen ist auch zuverlässiger als zu versuchen eine id aus dem namen zu extrahieren. vor allem weil die kennzeichung nicht gleich aufgebaut ist und sich zwischen den kategorieren und auch innerhalb unterscheiden. das automatische zuordnen bezog sich darauf das man damit dann z.b. alle parameter von heizkreis x erkennen kann. egal aus welcher kategorie sie kommen. das ist aber vermutlich nur nice to have. aktuell nicht wirklich wichtig.

die dinge aus der wunschliste die mit fhem bordmitteln nicht gehen kommen noch. nach und nach. je nach zeit :). als erstes das setzen von parametern. ich weiss nur noch nicht wie ich das mit testen mache. ich möchte mir nichts an meiner heizung zerschiessen und ich habe keine zweite nur zum testen :)

ich werde auch schauen das man im modul alles so vorbereitet und einbaut das die kombination mit anderen fhem modulen so einfach wie möglich ist.

Sind Schrägstriche und Punkte in den Readings erlaubt?

Ich habe Readings in folgender Art:

6800-Historie1Datum/Zeit
6810-Historie2Datum/Zeit

8300-1.BrennerstufeT2
8301-2.BrennerstufeT8

ja. sind erlaubt.

Macht es denn vielleicht dennoch Sinn, diese Zeichen aus den Readings zu entfernen?
Nicht, dass sich RegEx an den Punkten oder irgendwie Maskierungen an den Schrägstrichen stören.
Du bist der Profi: Was meinst du?

ich wüsste nicht warum es probleme geben sollte. beide zeichen sind explizit erlaubt und andere devices benutzen sie. der punkt bei 1-wire und der / bei mqtt oder mysensors.

der . in einer regex matched auch einen punt im reading. der / in der regex die als parameter verwendet wird geht auch.

Super, Ihr seid so schnell :-)

Guten Morgen,

läuft das pollen der Kategorien und Parameter bei Euch gut ?
Bei mir lief es eine weile und dan kommt "trying to poll". Und die Kategorien werden nicht alle gelesen.
Ich habe auch das Device wieder gelöscht und neu erstellt, das hat schonmal geholfen, aber auch dann
bekomme ich nicht die Kategorien und Parameter.
Meine anderen Abfragen des Arduino habe ich gestoppt. Der Abruf der Json Kategorien im Browser funktioniert gut.

Jens

Edit:
Jetzt bin ich hergegangen und habe die polls direkt eingetragen und einen reconnect gemacht:
8700,8730,8731,8732,8740,8741,8743,8744,8760,8761,8762,8770,8771,8773,8774,700,710,712,720,721,750,760,900,8000,1000,1010,1012,1020,1021,1050,1060,1200,8001
Im Logfile kommt dann :
2018.03.22 09:42:47 3: Broejte: trying to connect.
2018.03.22 09:42:47 4: Broejte: connected.
2018.03.22 09:42:52 4: Broejte: trying to poll.
2018.03.22 09:42:53 4: Broejte: got data for 8700,8730,8731,8732,8740,8741,8743,8744,8760,8761,8762,8770,8771,8773,8774,700,710,712,720,721,750,760,900,8000,1000,1010,1012,1020,1021,1050,1060,1200,8001

2018.03.22 10:00:23 4: Broejte: trying to poll.
2018.03.22 10:00:23 5: Broejte: received <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>BSB-LAN Web</title>
<link rel="shortcut icon" type="image/x-icon" href="http://arduino.cc/en/favicon.png" />
<style>A:link  {color:blue;text-decoration: none;} A:visited {color:blue;text-decoration: none;} A:hover {color:red;text-decoration: none;background-color:yellow} A:active {color:blue;text-decoration: none;} A:focus {color:red;text-decoration: none;}
input {width: 100%; box-sizing: border-box;} select {width: 100%;}</style>
</head><body>
<script>function set(line,formnr){
if(isNaN(document.getElementById('value'+formnr).value)==false){
window.open('S'+line+'='+document.getElementById('value'+formnr).value,'_self');
}}
function setbit(line,formnr){
var x=document.getElementById('value'+formnr); var value=0;
for (var i=0; i<x.options.length; i++) {
if(x.options[i].selected){
value=value+eval(x.options[i].value);
}}
window.open('S'+line+'='+value,'_self');
}</script>
<font face='Arial'>
<center><h1><A HREF='/2201/'>BSB-LAN Web</A></h1></center>
<table width=80% align=center><tr bgcolor=#f0f0f0><td width=20% align=center><a href='/2201/K'>Heizungsfunktionen</a></td><td width=20% align=center><font color=#000000>DS18B20-Sensoren</font></td><td width=20% align=center><font color=#000000>DHT22-Sensoren</font></td><td width=20% align=center><a href='/2201/DG'>Anzeige Logdatei</a></td></tr><tr bgcolor=#f0f0f0><td width=20% align=center><a href='/2201/C'>Konfiguration</a></td><td width=20% align=center><a href='/2201/O'>URL-Befehle</a></td><td width=20% align=center><a href='http://github.com/fredlcore/bsb_lan/blob/master/HOWTO_de.md' target='new'>HowTo</a></td><td width=20% align=center><a href='http://github.com/fredlcore/bsb_lan/blob/master/FAQ_de.md' target='_new'>FAQ</a></td>
</tr></table><p></p><table align=center width=80%><tr><td>
</td></tr></table>
</body>
</html>


2018.03.22 10:00:23 4: Broejte: got data for 8700,8730,8731,8732,8740,8741,8743,8744,8760,8761,8762,8770,8771,8773,8774,700,710,712,720,721,750,760,900,8000,1000,1010,1012,1020,1021,1050,1060,1200,8001
2018.03.22 10:00:23 5:        $VAR1 = {};


Im Device erscheinen keine readings oder Kategorien. Nach dem ich den verbose nun auf 5 gestellt habe sieht man das nichts kommt.

Zitat von: Jewe am 22 März 2018, 09:41:41

Code Auswählen Erweitern


2018.03.22 10:00:23 4: Broejte: got data for 8700,8730,8731,8732,8740,8741,8743,8744,8760,8761,8762,8770,8771,8773,8774,700,710,712,720,721,750,760,900,8000,1000,1010,1012,1020,1021,1050,1060,1200,8001
2018.03.22 10:00:23 5:        $VAR1 = {};


Drei Gedanken dazu (nur zwei ernst gemeint):
1.: Broejte -> Der Regler fühlt sich nicht angesprochen, weil er nicht Broejte heißt (Spaß muss sein ;) )..
2.: Verdammt viele Abfragen - 33 Stück in welchem Intervall? 60Sek? Vielleicht zu viele in einem zu kurzen Intervall? -> Das nur als grundsätzlicher Gedanke, Problem wird Nr3 sein:
3.: Da es justme1968 schonmal schrieb:  $VAR1 = {} -> Dein Regler liefert keine Daten. Da du das schonmal hattest (oder war das jmd anderes?): Hast du die Verkabelung mal auf Wackelkontakte überprüft? LED am Adapter leuchtet und flackert? Zugriff via Webinterface funktioniert?

EDIT: Doch, das warst du, s. vorherige Seite. justme1968's Antwort darauf: https://forum.fhem.de/index.php/topic,84381.msg783690.html#msg783690

Ja Gedanke 1. ist bestimmt richtig, so eine beleidigte Leberwurst. :-)
3. kann ich ausschliessen, da passt alles. Mit den HTTPMOD´s läuft es
2. Ja, ist schon viel. Den Intervall habe ich nicht veändert. Stelle jetzt mal auf 5 min.

Vermute gerade, dass es evtl. auch am timeout liegen könnte, wenn das Brötchen länger braucht ?

Edit:

Zitat von: Schotty am 22 März 2018, 10:36:46
EDIT: Doch, das warst du, s. vorherige Seite. justme1968's Antwort darauf: https://forum.fhem.de/index.php/topic,84381.msg783690.html#msg783690

Ja, war ich, aber die Installation ist ok. Bei der HTTPMOD abfrage und über WebInterface gibt es keine Störungen.

Hallo zusammen,
Ich hab ein kleines Problem mit dem Modul:
Ich erhalte bei der Abfrage in den readings state category 30 failed als Anwort, wenn ich die Konfiguration abfrage.
Ich habe heute nur das Modul neu in FHEM installiert. Müssen die beiden anderen Files auch getauscht werden oder weshalb läßt sich die Konfiguration nicht laden?

edit: lt. SerMon wird ein /JK=30 gesendet, aber nichts zurückgesendet
Gruß Uwe

@postman: was passiert wenn du die gleiche anfrage mit einem browser probierst?

@freeze: ich habe angefangen das setzen von werten einzubauen. dabei ist mir vorab aufgefallen:

- die abfrage von /JK=41 landet in einer endlosschleife bei der mitten in 10510 nur noch unsinn ausgegeben wird.
- für die parameter 701 und 1001 (Präsenztaste) gibt es keine possibleValues.
- das gleiche für 1601
- aktuell gibt es noch keine möglichkeit an den ausgelesenen daten zu sehen ob ein parameter überhaupt setzbar ist und/oder ob das setzen freigeschaltet ist.

Hey,
inzwischen habe ich es nochmal probiert. RasPi und Arduino neu gestartet und dann neu definiert.
Leider keine Änderung.

Ist das mit dem Passwort so richitg ?
define Broetje BSB 192.168.6.23/1234/

Festgestellt habe ich auch, wenn ich im Browser http://192.168.6.23/1234/K11 aufrufe bekomme ich sofort die Daten angezeigt.
Mache ich das selbe im Browser mit http://192.168.6.23/1234/JK11 bekomme ich nicht´s ?

Siehe auch :
https://forum.fhem.de/index.php/topic,84381.msg785006.html#msg785006

Zitat von: Jewe am 22 März 2018, 17:35:04
Mache ich das selbe im Browser mit http://192.168.6.23/1234/JK11 bekomme ich nicht´s ?

Also wenn, dann müsste es auch (...)/JK=11 heißen glaube ich..

Zitat von: Schotty am 22 März 2018, 17:41:54
Also wenn, dann müsste es auch (...)/JK=11 heißen glaube ich..

Danke, ja so bekomme ich dann auch sofort die Daten als JSON angezeigt. Nur in FHEM mit den BSB Modul nicht.

bitte stell mal verbose auf 5 und schau noch mal ins log.

Hallo justme1968,
wenn ich das im Browser (firefox) eingebe erhalte ich folgendes:
SyntaxError: JSON.parse: bad control character in string literal at line 754 column 54 of the JSON data

Vorher werden aber alle Parameter als reine Textausgabe angezeigt. Das ist aber soviel, dass es sich leider nicht kopieren läßt. Am Ende steht dann der oben angegebene Satz im Browser.

Gruß Uwe

Zitat von: justme1968 am 22 März 2018, 17:51:35
bitte stell mal verbose auf 5 und schau noch mal ins log.

2018.03.22 19:08:53 4: Broetje: trying to poll.
2018.03.22 19:09:00 4: Broetje: trying to poll.
2018.03.22 19:09:05 4: Broetje: trying to query categories.
2018.03.22 19:09:05 5: Broetje: received <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>BSB-LAN Web</title>
<link rel="shortcut icon" type="image/x-icon" href="http://arduino.cc/en/favicon.png" />
<style>A:link  {color:blue;text-decoration: none;} A:visited {color:blue;text-decoration: none;} A:hover {color:red;text-decoration: none;background-color:yellow} A:active {color:blue;text-decoration: none;} A:focus {color:red;text-decoration: none;}
input {width: 100%; box-sizing: border-box;} select {width: 100%;}</style>
</head><body>
<script>function set(line,formnr){
if(isNaN(document.getElementById('value'+formnr).value)==false){
window.open('S'+line+'='+document.getElementById('value'+formnr).value,'_self');
}}
function setbit(line,formnr){
var x=document.getElementById('value'+formnr); var value=0;
for (var i=0; i<x.options.length; i++) {
if(x.options[i].selected){
value=value+eval(x.options[i].value);
}}
window.open('S'+line+'='+value,'_self');
}</script>
<font face='Arial'>
<center><h1><A HREF='/2201/'>BSB-LAN Web</A></h1></center>
<table width=80% align=center><tr bgcolor=#f0f0f0><td width=20% align=center><a href='/2201/K'>Heizungsfunktionen</a></td><td width=20% align=center><font color=#000000>DS18B20-Sensoren</font></td><td width=20% align=center><font color=#000000>DHT22-Sensoren</font></td><td width=20% align=center><a href='/2201/DG'>Anzeige Logdatei</a></td></tr><tr bgcolor=#f0f0f0><td width=20% align=center><a href='/2201/C'>Konfiguration</a></td><td width=20% align=center><a href='/2201/O'>URL-Befehle</a></td><td width=20% align=center><a href='http://github.com/fredlcore/bsb_lan/blob/master/HOWTO_de.md' target='new'>HowTo</a></td><td width=20% align=center><a href='http://github.com/fredlcore/bsb_lan/blob/master/FAQ_de.md' target='_new'>FAQ</a></td>
</tr></table><p></p><table align=center width=80%><tr><td>
</td></tr></table>
</body>
</html>


2018.03.22 19:09:05 4: Broetje: got categories.
2018.03.22 19:09:05 5:        $VAR1 = {};


@postman: schau mal ob du rausfindest welche zeile mit 754 in der parameter ausgabe gemeint sein könnte.

@Jewe: dein sketch antwortet mit einer leeren kategorien liste. was bekommst du im browser bei .../JK=ALL ?

Zitat von: justme1968 am 22 März 2018, 16:58:15
- die abfrage von /JK=41 landet in einer endlosschleife bei der mitten in 10510 nur noch unsinn ausgegeben wird.

Das hat (leider) nichts mit dem JSON-Export zu tun, sondern ist ein Problem bei der Adressierung von Strings im Bereich > 64kB, die ich nicht direkt mit char Pointern ansprechen kann. Mein Getrickse basiert darauf zu wissen, welcher String die niedrigste Adresse hat, und das scheint jetzt 10510 zu sein. Davon abgesehen ist die Kategorie für BSB eh' nicht relevant, da es die PPS-Kategorie ist. Da das zwar nicht notwendigerweise die Kategorie 41 ist, aber immer die letzte sein wird, kannst Du auch einfach die ausgelesenen Kategorien um den letzten Eintrag kürzen.

Zitat
- für die parameter 701 und 1001 (Präsenztaste) gibt es keine possibleValues.
- das gleiche für 1601

Das ist auch kein Typ ENUM, sondern einer der "proprietären" ENUMs (wie z.B. bei on/off, closed/open oder yes/no), die auf 0/1 Werten basieren. Ist nicht die reine Lehre, aber nicht auf meinem Mist gewachsen, und jetzt den Code zu durchforsten, um das alles in ENMUs abzuwandeln, fehlt mir momentan die Zeit. Deswegen übermittle ich wie bei anderen numerischen Werten den Typ DT_VALS. Wenn ich (oder jemand anderes :) ) diese Parameter auf ENUMs umstellt, werden da auch wie bei den anderen Parametern, die auf diesen Datentypen beruhen, automatisch auch die possibleValues kommen.

Zitat
- aktuell gibt es noch keine möglichkeit an den ausgelesenen daten zu sehen ob ein parameter überhaupt setzbar ist und/oder ob das setzen freigeschaltet ist.

Das könnte ich wohl noch nachreichen, aber ich meine, dass zumindest der Return-Code aussagt, ob der Parameter read-only war. Auch wenn es sicherlich nice to have wäre, das schon vorher zu wissen.

Hallo justme1968,
ich glaube, ich habe mich weiter oben etwas ungenau ausgedrückt.
Also, wenn ich IP/JK=30 im browser aufrufe, erhalte ich eine Rückgabe von Daten. Dabei kann ich mit 3 Schaltflächen auf der Seite "JSON" anklicken, in der die obige Fehlermeldung steht, mit einer zweiten Schaltfläche kann ich mir die Rohdaten anzeigen lassen, die bis auf die letzten Werte mit der Ausgabe im BSB übereinstimmen und eine dritte Schaltfläche, die mir Kopfzeilen anzeigt.

Zitatschau mal ob du rausfindest welche zeile mit 754 in der parameter ausgabe gemeint sein könnte.

"5950": {
    "name": "Funktion Eingang H1",
    "possibleValues": [
      { "enumValue": "0", "desc": "Keine" },
      { "enumValue": "1", "desc": "BA-Umschaltung HK's + TWW" },
      { "enumValue": "2", "desc": "BA-Umschaltung TWW" },
      { "enumValue": "3", "desc": "BA-Umschaltung HK's" },
      { "enumValue": "4", "desc": "BA-Umschaltung HK1" },
      { "enumValue": "5", "desc": "BA-Umschaltung HK2" },
      { "enumValue": "6", "desc": "BA-Umschaltung HK3" },
      { "enumValue": "7", "desc": "Erzeugersperre" },
      { "enumValue": "8", "desc": "Fehler- / Alarmmeldung" },
      { "enumValue": "9", "desc": "Verbr'anforderung VK1" },
      { "enumValue": "10", "desc": "Verbr'anforderung VK2" },
      { "enumValue": "11", "desc": "Freigabe Schw'bad Erzeuger" },
      { "enumValue": "12", "desc": "Übertemperaturableitung" },
      { "enumValue": "13", "desc": "Freigabe Schw'bad Erzeuger Solar" },
      { "enumValue": "14", "desc": "Betriebsniveau TWW" },
      { "enumValue": "15", "desc": "Betriebsniveau HK1" },
      { "enumValue": "16", "desc": "Betriebsniveau HK2" },
      { "enumValue": "17", "desc": "Betriebsniveau HK3" },
      { "enumValue": "18", "desc": "Raumthermostat HK1" },
      { "enumValue": "19", "desc": "Raumthermostat HK2" },
      { "enumValue": "20", "desc": "Raumthermostat HK3" },
      { "enumValue": "22", "desc": "Trinkwasserthermostat" },
      { "enumValue": "23", "desc": "Zirk'pumpenthermostat" },
      { "enumValue": "24", "desc": "Impulszählung" },
      { "enumValue": "29", "desc": "Startverhinderung  Kessel-Rückflussthermostat" },
      { "enumValue": "50", "desc": "Durchflussmessung Hz" },
      { "enumValue": "51", "desc": "Verbraucheranforderung VK1 10V" },
      { "enumValue": "52", "desc": "Verbraucheranforderung VK2 10V" },
      { "enumValue": "56", "desc": "Raumtemperatur 10V" }
    ],
    "dataType": 1
  },

die Zeile 754 ist der Parameter 19 mit dieser Ausgabe:   { "enumValue": "19", "desc": "Raumthermostat HK2" },

Ich weiss aber nicht, ob ich an der richtigen Stelle gesucht habe. Die column 54 wäre die "2" von HK2. Etwas verwirrend für mich  :-[

Ich habe die gesammte Ausgabe der Rohdaten mal in eine Textdatei umgeleitet und gespeichert. Ich hänge die mal hier ran, vielleicht kannst Du da mehr mit anfangen.

Gruß Uwe

Zitat von: justme1968 am 22 März 2018, 23:19:51
@Jewe: dein sketch antwortet mit einer leeren kategorien liste. was bekommst du im browser bei .../JK=ALL ?

Sieht glaube ich gut aus.

{

"0": { "name": "Uhrzeit und Datum", "min": 0, "max": 6 },

"1": { "name": "Bedieneinheit", "min": 20, "max": 70 },

"2": { "name": "Funk", "min": 120, "max": 140 },

"3": { "name": "Zeitprogramm Heizkreis 1", "min": 500, "max": 516 },

"4": { "name": "Zeitprogramm Heizkreis 2", "min": 520, "max": 536 },

"5": { "name": "Zeitprogramm 3/HKP", "min": 540, "max": 556 },

"6": { "name": "Zeitprogramm 4", "min": 560, "max": 576 },

"7": { "name": "Zeitprogramm 5", "min": 600, "max": 616 },

"8": { "name": "Ferien Heizkreis 1", "min": 632, "max": 648 },

"9": { "name": "Ferien Heizkreis 2", "min": 649, "max": 665 },

"10": { "name": "Ferien Heizkreis P", "min": 666, "max": 682 },

"11": { "name": "Heizkreis 1", "min": 700, "max": 900 },

"12": { "name": "Kühlkreis 1", "min": 901, "max": 969 },

"13": { "name": "Heizkreis 2", "min": 1000, "max": 1200 },

"14": { "name": "Heizkreis 3/P", "min": 1300, "max": 1500 },

"15": { "name": "Trinkwasser", "min": 1600, "max": 1680 },

"16": { "name": "Hx-Pumpe", "min": 2008, "max": 2051 },

"17": { "name": "Schwimmbad", "min": 2055, "max": 2080 },

"18": { "name": "Vorregler/Zubringerpumpe", "min": 2110, "max": 2150 },

"19": { "name": "Kessel", "min": 2200, "max": 2551 },

"20": { "name": "Sitherm Pro", "min": 2700, "max": 2732 },

"21": { "name": "Wärmepumpe", "min": 2785, "max": 3010 },

"22": { "name": "Energiezähler", "min": 3095, "max": 3267 },

"23": { "name": "Kaskade", "min": 3510, "max": 3590 },

"24": { "name": "Zusatzerzeuger", "min": 3700, "max": 3723 },

"25": { "name": "Solar", "min": 3810, "max": 3887 },

"26": { "name": "Feststoffkessel", "min": 4102, "max": 4141 },

"27": { "name": "Pufferspeicher", "min": 4708, "max": 4813 },

"28": { "name": "Trinkwasserspeicher", "min": 5010, "max": 5131 },

"29": { "name": "Trinkwasser Durchl'erhitzer", "min": 5400, "max": 5544 },

"30": { "name": "Konfiguration", "min": 5700, "max": 6421 },

"31": { "name": "LPB-System", "min": 6600, "max": 6650 },

"32": { "name": "Fehler", "min": 6705, "max": 6846 },

"33": { "name": "Wartung/Sonderbetrieb", "min": 7001, "max": 7254 },

"34": { "name": "Ein-/Ausgangstest", "min": 7700, "max": 7999 },

"35": { "name": "Status", "min": 8000, "max": 8099 },

"36": { "name": "Diagnose Kaskade", "min": 8100, "max": 8150 },

"37": { "name": "Diagnose Erzeuger", "min": 8300, "max": 8570 },

"38": { "name": "Diagnose Verbraucher", "min": 8700, "max": 9075 },

"39": { "name": "Feuerungsautomat", "min": 9500, "max": 9627 },

"40": { "name": "Benutzerdefiniert", "min": 10000, "max": 10000 },

"41": { "name": "PPS-Bus", "min": 10500, "max": 10515 }

}



Zitat von: postman am 23 März 2018, 00:22:28
die Zeile 754 ist der Parameter 19 mit dieser Ausgabe:

Code Auswählen Erweitern

  { "enumValue": "19", "desc": "Raumthermostat HK2" },

Ich weiss aber nicht, ob ich an der richtigen Stelle gesucht habe. Die column 54 wäre die "2" von HK2. Etwas verwirrend für mich  :-[

Also wenn ich mir das txt-file so ansehe, dann ist (zumindest nach der Zählung des Editors) Z.754/C.54 die Nr.29 von Parameter 5950, da taucht direkt hinter "Startverhinderung" auch ein komisches Zeichen auf, das der Grund für das Problem sein dürfte - s. screenshot im Anhang (Zeichen habe ich orange markiert).

...liegt nicht am Modul, da fehlte in der ENUM-Auflistung in der Zeile ein abschließendes \0 - habe das jetzt gefixt; auch JK=41 sollte hoffentlich nicht mehr in einer Endlosschleife enden, ansonsten muss ich mir das noch mal im Detail genauer anschauen, bin jetzt erst mal eine Woche auf Dienstreise, dann ist Ostern, könnte also dauern...

ja. das ist es.

im BSB_lan_defs.h fehlt in zeile 2549 am ende des strings ein \0. dadurch wird der nachfolgende parameter 30 mit ans ende von parameter 29 gehängt und die 30 (\x1e) als ascii zeichen interpretiert bei dem dann der json parser aussteigt.

einfach das header file korrigieren und den sketch neu kompilieren.

Zitat von: freetz am 22 März 2018, 23:42:11
Davon abgesehen ist die Kategorie für BSB eh' nicht relevant, da es die PPS-Kategorie ist.

Das ist überhaupt ein guter Hinweis - daher mal ganz doof nachgefragt @justme1968:
Derzeit entwickelst du das Modul ja für die Anbindung via BSB, also auch mit einer (quasi festen) Geräteadresse für Adapter und Ziel-Regler.
Wie sieht es mit der Nutzung des LPB bzw. für den LPB aus?
Gerade wenn zwei oder mehr Regler im LPB-Verbund vorhanden sind (Bsp: normaler Kesselregler + SSR für Solar etc + vielleicht auch noch ein ZR) und nicht jeder Regler einen Adapter mit eigener IP und entspr. nur lokalem Zugriff auf den direkt angeschlossenen Regler hat?
In dem Fall wäre es natürlich großartig, wenn man dann für LPB-Nutzung auch noch das komfortable Klicken hinsichtlich der auswählbaren Regler hätte, also bspw. einstellbare Geräteadresse (des Adapters, wobei man das sicherlich auch auf die config.h beschränkt lassen könnte), einstellbare Zieladresse(n) für die jeweils anzusprechenden Regler, pro Zieladresse/Regler dann die entsprechende Kategorie-&Parameterabfrage und -auswahl etc.
Eben so, dass man mit dem Modul bspw Parameter a,b,c,d,e von Regler1, Parameter c,g,h,x,y von Regler2 und Parameter a,l,p,y,z von Regler3 abrufen und weiterverarbeiten könnte. (Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt - besser weiß ich es gerade nicht zu beschreiben.. ;) )

Zitat von: justme1968 am 23 März 2018, 12:33:46
einfach das header file korrigieren und den sketch neu kompilieren.

Damit wäre aber nicht der (vermutliche) Grund für die Endlosschleife bei /JK=41 behoben...

ich habe mir noch überhaupt nicht angeschaut wie das mit mehreren reglern funktioniert :)

die idee ist schon das das modul universell ist und mit allem klar kommt das vom board ausgespuckt wird.

wie würde denn aktuell die json ausgabe bei mehreren reglern aussehen? geht das überhaupt?
wie schaut die html seite aus?

ohne genau nachgelesen zu haben würde ich mal sagen das man auf der obersten ebene noch einen knoten in der json ausgabe vorsieht mit der der regler identifiziert wird. in jedem regler knoten steckt dann die ausgabe wie es sie bisher gibt. konsequenter weise wäre es am einfachsten wenn man für die bsb ausgabe diesen knoten auch vorsieht. halt nur ein mal. also ein hash von reglern jeweils mit namen und kategorien.

beim setzen müsste man auch angeben auf welchem regler etwas gesetz werden soll. geht das mit der .../S url überhaupt? für die json variante müsste man auch etwas einbauen.


@freetz: natürlich nicht. das war nur der quick fix für das json problem den ich schnell geschrieben hatte bevor du gepostet hast.

Zitat von: justme1968 am 23 März 2018, 12:48:06
beim setzen müsste man auch angeben auf welchem regler etwas gesetz werden soll. geht das mit der .../S url überhaupt? für die json variante müsste man auch etwas einbauen.

Diesbzgl habe ich leider auch noch keine Erfahrungswerte, ich kann nur zitieren, was ich im Handbuch geschrieben habe (also wie es theoretisch funktionieren müsste):
Setze Wert <v> (value) für den Parameter <x> mit optionalem Ziel <z>:
http://<IP-Adresse>/S<x>=<v!z>
Die gewünschte Gerätezieladresse ist als <z> einzufügen, wenn <!z> nicht eingegeben wird, wird die Standardzieladresse verwendet.

Bei der reinen Verwendung des LPB sollte der Bustyp in der config.h ja eigtl schon angepasst sein (P=1=LPB, per default ist es 0=BSB), hier trotzdem nochmal die Beschreibung für den Wechsel der eigenen oder der Zieladresse per URL-Befehl:
Zusätzlich die eigene oder die Zieladresse mittels URL-Befehl wechseln:
Dazu muss der Befehl
http://<IP-Adresse>/P<x,y,z>
genutzt werden, wobei
<x> = Bus (0 = BSB, 1 = LPB, 2 = PPS),
<y> = eigene Adresse (default 0x06 = RGT1) und
<z> = Zieladresse (default 0x00 = Geräteadresse 1) sind.
Leerwerte bei den Adressen belassen den bisherigen Wert (= Adresse).

Mehr kann ich dazu derzeit leider nicht wirklich beisteuern.. :(

Hallo zusammen,
danke für die Hilfe. Ich werde also die Version mit der Bereinigung noch einmal neu installieren.
Ich habe mir die Daten mal mit Word angesehen; da steht hinter der Startverhinderung ein "-" und im normalen Texteditor ein senkrecht stehendes Rechteck.
Mal so nebenbei: Euer Support ist super ;D
Da könnte sich so manch ein Unternehmen mal ein Beispiel dran nehmen, zumal alle, die hier im forum Hilfe und Support leisten, dass als Hobby betreiben.
So das musste mal gesagt werden ;D ;D ;)


Ich hab noch mal eine Frage: Mir ist aufgefallen, das in den Readings als Werte nur die Zahlen (z.b. 114 bei 8000 Status - Status Heizkreis 1:) ausgegeben werden und nicht wie im Web auch der Klartext wie hier zu sehen
8000 Status - Status Heizkreis 1: 114 - Heizbetrieb Komfort

Ist das möglich, das entsprechend einzubinden, das auch der Klartext zu sehen ist?

Gruß Uwe

Zitat von: justme1968 am 23 März 2018, 12:48:06
ohne genau nachgelesen zu haben würde ich mal sagen das man auf der obersten ebene noch einen knoten in der json ausgabe vorsieht mit der der regler identifiziert wird. in jedem regler knoten steckt dann die ausgabe wie es sie bisher gibt.

..und man dann im Modul die Auswahl der automatisch erkannten Regler sehen würde, die man wiederum wie bisher einzeln konfigurieren könnte..?! DAS wäre natürlich mal richtig sexy ;)

Zitat..und man dann im Modul die Auswahl der automatisch erkannten Regler sehen würde, die man wiederum wie bisher einzeln konfigurieren könnte..?! DAS wäre natürlich mal richtig sexy ;)

genau das wäre die idee dabei :)

Dann bitte einfach mal sammeln, was wie wo noch in die JSON-Struktur aufgenommen werden soll und dann mal ein Muster posten, dann passe ich das so an - ansonsten verliere ich glaube ich langsam den Überblick ;)...

@justme1968:
Mal kurz was ganz anderes:

Zitat von: justme1968 am 20 März 2018, 13:16:47
als erstes das setzen von parametern. ich weiss nur noch nicht wie ich das mit testen mache. ich möchte mir nichts an meiner heizung zerschiessen und ich habe keine zweite nur zum testen :)

Meinst du mit "Zerschießen" deine Hzgs-Reglerkonfig/-einstellungen? Oder wirklich 'physische' Schäden..?

Wenn's was hilft: Das Setzen als solches habe ich schon getestet, die Frage ist halt nur, ob es im Kontext des Moduls auch so passt. Und Du kannst zum Testen ja unverfängliche Parameter wie die Komfort-Temperatur nehmen. Darüber hinaus hat die Theme schon einiges an Sicherheitsvorkehrungen. Z.B. kann keine Ziel, Temperatur über 35 Grad gesetzt werden. Was nicht heißen sollte, dass man bei den OEM-Parametern nicht schon auch die Funktionsweise gründlich durcheinander bringen kann. Aber mit einem Backup der Einstellungen (0-10000) sollte man auch da das meiste wieder fixen können...

mir ging es weniger um dauerhafte schäden, aber wenn mitten im winter die heizung aus versehen einen tag nicht tut oder morgens kein wasser zum duschen da ist wäre das eine mittlere katastrophe für den rest des haushalts :)

json vorschlag mache ich sobald ich etwas zeit habe.

Zitat von: Jewe am 23 März 2018, 08:20:55
Sieht glaube ich gut aus.

Code Auswählen Erweitern

{

"0": { "name": "Uhrzeit und Datum", "min": 0, "max": 6 },

"1": { "name": "Bedieneinheit", "min": 20, "max": 70 },


Hey, hat jemand noch eine Idee zu meinem Problem, dass das BSB-Modul nicht mehr will. Es ging ja mal kurz und dann eben nicht mehr.

Zitat von: Jewe am 27 März 2018, 22:08:22
Hey, hat jemand noch eine Idee zu meinem Problem, dass das BSB-Modul nicht mehr will. Es ging ja mal kurz und dann eben nicht mehr.

Hallo,
gestern habe ich ein update von Fhem gemacht und danach wieder das Modul probiert. Leider keine Änderung meines Problems. Anscheinend habe nur ich das Problem. Was kann ich den noch ausprobieren?

Jens

Gesendet von meinem F5121 mit Tapatalk

Man möge mir folgenden Kommentar verzeihen. Er ist nicht böse gemeint.

Ich habe bis heute noch nicht auf das neue Modul umgestellt, da
- mir noch (für mich) elementare Funktionen fehlen (Setter) und
- die Oberfläche in vielen Skins (außer "dark") unbedienbar ist (okay, notfalls gehe ich über die Attribute)

Der Kern meiner Hausautomatisierung ist das gesamte Heizungssystem. Darauf muss ich mich halt verlassen. Das Ding ist bei mir mittlerweile sehr komplex geworden. Plots, Überwachung, Konfiguration usw. Da wechselt man nicht so schnell auf eine Beta-Version.

Ich sage das hier nicht als Kritik, sondern eher als Begründung, wieso ich seit meinen letzten Beiträge/Patches hierzu ruhiger geworden bin.

Ich vertraue Andre hier blind. Er weiß was er tut und er hat auch zig andere Module (die mir auch wichtig sind) in der Entwicklung.

Ich hoffe, dass seine Motivation an diesem Modul bestehen bleibt.

updates kommen demnächst wieder. nächste woche habe ich ein test system. das macht einiges einfacher. und dann kommen als erstes die setter.

Bleib uns (der FHEM-Community) bitte auf ganz lange Zeit erhalten! Du bist Gold wert.

@freetz: ich baue gerade ein das fhem vor dem flashen des hex file die mac und ip patched. damit kann man dann eine standard version mit ausliefern und muss nicht mehr selber kompilieren wenn es nur im diese beiden änderungen geht. aber das binäre patchen ist natürlich nicht ganz sauber. funktioniert aber.

eine alternative wäre wenn man die beiden adressen optional aus dem eeprom holen könnte. z.b wenn beides im sketch auf 0 initialisiert ist wird der wert aus dem eeprom geholt. das einmalige beschreiben des eeproms könnte man dann z.b. über ein serielles kommando machen. meinst du der code passt noch in den speicher?

Das wäre an sich eine schöne Idee, die vom reinen Speicherplatz her auch noch passen würde, allerdings habe ich bei meinem Robotan-Projekt gemerkt, dass zumindest beim ESP8266 das EEPROM nicht standardmäßig bzw. durchgängig auf Null ist. Bei manchen ist es auf 00, bei andern auf  FF, bei wieder anderen auch noch durchwachsener. Ich müsste im Script ja einen eindeutigen "Leerzustand" abfragen, um in dem Fall den Wert aus der Config zu nehmen, und nur dann das EEPROM verwenden, wenn der Bereich dort nicht "leer" ist. Man könnte evtl. ein bestimmtes Byte als Marker nehmen und das auf einen bestimmten Wert setzen, und wenn das gesetzt ist, wird aus einem anderen Bereich die IP übernommen. Bei einer zufälligen Werteverteilung im EEPROM könnte es dann zwar immer noch zu false positives kommen, aber wohl dann doch eher selten.

Würde ich mir aber erst dann auf ToDo setzen, wenn die anderen Punkte mit JSON etc. endgültig abgeschlossen sind, ok?

das mit dem 'leerzustand' ist glaube ich nicht so problematisch.

in unserem fall müssen wir ja nicht entscheiden ob der eeprom wert gültig ist, sondern nur ob der wert aus dem sketch gültig ist oder ob das eeprom gelesen werden soll. d.h. wenn im sketch der 'leerzustand' einkompiliert ist (d.h. kein wert explizit gesetzt) dann wird der wert aus dem eeprom genommen. egal was dort steht. wenn da auch nichts sinnvolles steht ist das egal. mit dem wert aus dem sketch wäre es ja auch nicht gegangen. der default wert im eeprom ist also egal und nur der default wert im hex file wichtig. und der ist eindeutig.

den wert im eeprom könnte man auf zwei arten setzen: per seriell und aus dem sketch und zusätzlich wenn etwas einkompiliert ist diesen wert auch schreiben.

eilt nicht. zum testen patche ich erst mal weiter binär :). das ist schon mal besser als immer wieder den quelltext zu editieren und für das jeweilige system anzupassen und dann aus versehen doch aufs falsche board zu flashen :(

ansonsten: ich habe inzwischen ein zweites system nur zum testen und es kommt demnächst eine version des moduls mit set kommandos.

Ok, dann würdest Du eine Version kompilieren, bei der die IP-Adresse leer ist (anstatt wie jetzt mit der entsprechenden IP belegt)? Das wäre natürlich einfacher umzusetzen.
Den in der _config.h gesetzten Wert noch ins EEPROM schreiben macht, wenn man die oben genannte Bedingung zur Grundlage nimmt, aber wenig Sinn, weil beide Werte dann eigentlich immer gleich wären (außer man setzt zuerst den Wert in der Config und löscht ihn dann später, aber wozu?). Wenn man das EEPROM direkt per USB beschreiben kann, wäre die Sache ja wirklich relativ überschaubar, dann bräuchte ich am Anfang nur die Überprüfung und das Einlesen umzusetzen, und wir müssten den Speicherbereich festlegen.

ja. mac und ip leer bzw. mit einem eindeutigen, aber nicht sinnvollen default belegt. dann wird alles aus dem eeprom gelesen.

avrdude kann das eeprom beschreiben, aber scheinbar unterstütz es der bootloader der meisten arduinos nicht. ob es beim atmega2560 geht habe ich noch nicht probiert. deshalb der weg über die config. d.h. man müsste ein mal einen passend konfigurierten sketch flashen, dieser schreibt die werte beim start ins eeprom und beim flashen später kann man dann den default sketch verwenden.

die kür wäre natürlich das seriell initialisieren auch im sketch zu unterstützen. eigentlich nicht aufwändig, aber das braucht natürlich mehr code und muss implementiert werden. deshalb der einfache workaround über die config.


falls wir das mit dem eeprom nicht einbauen: könntest du in der config.h mac und ip direkt hintereinander ins gleiche array stecken: byte network[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xEA, 0x00, 0x00, 0x00, 0x00} dann wäre beim binär patchen das risiko für einen konflikt kleiner.

ps: wie schaut es eigentlich mit der netmask aus? woher kennt der sketch die?

Aber dann müsste der User ja doch wieder vor der ersten Benutzung die ganze IDE etc. installieren, kompileren usw.
Wäre es da nicht einfacher einen eigenen Mini-Sketch zu haben, der ohne IDE sondern nur mit avr-gcc kompiliert wird und nichts anderes macht, als die IP ins EEPROM zu schreiben? Dann könnte im Anschluss der fertig kompilierte BSB_LAN-Sketch hochgeladen werden und die User müssten sich um gar nichts mehr kümmern.

Wenn das nicht ohne Weiteres möglich ist, würde ich es eher so umsetzen, dass auf der seriellen Schnittstelle auf ein Signal gelauscht wird, dem dann die IP folgt, die dann ins EEPROM geschrieben wird. Mehr Aufwand, aber würde den Usern die Installation und Konfiguration der IDE ersparen, und nur darin sähe ich einen wirklichen Mehrwert, das über FHEM flashbar zu machen, denn wenn man die IDE sowieso schon auf dem Rechner hat, kann man von dort ja auch direkt flashen.

Netmask ist standardmäßig 255.255.255.0. Bisher gab es noch keine Notwendigkeit das auch noch konfigurierbar zu machen, auch wenn es natürlich ginge...

wenn du den code für das auslesen eines seriellen kommandos zum setzen der werte noch in den sketch bekommst ist das natürlich noch besser. die diversen anderen arduino sketches die es für fhem gibt machen das ja auch so.

aber die idee mit dem mini sketch ist auch gut. aber gleich noch einen schritt weiter: der mini sketch bekommt serielle kommandos um per terminal die daten ins eeprom zu schreiben. dann muss man ebenfalls nichts mehr kompilieren. den code könnte man dann später mal in den bsb sketch übernehmen.

ob mini sketch oder gleich im bsb hängt dann eigentlich nur noch davon ab ob der mini sketch einfacher zum testen ist oder ob man es gleich richtig macht.

der rechner an dem das board hängt muss übrigens nicht der gleiche sein auf dem die idee läuft. ich habe z.b. im keller einen raspberry der nur 1wire macht und an dem das board per usb hängt. fhem läuft auf einem zweiten system und zum entwickeln verwende ich noch mal zwei andere rechner..

ich habe aktuell ein 255.255.255.0 netz, muss/will aber demnächst auf 255.255.0.0 wechseln. an sich kein grosser aufwand da ich sowieso schon 10.0.1.x ip adressen verwende, aber ohne die passende netmask im sketch problematisch.


also die idee noch mal zusammen gefasst:

- der bsb sketch bekommt die möglichkeit mac, ip und netmask aus dem eeprom auszulesen wenn die werte aus der config auf 'leer' initialisiert sind.

- es gibt im bsb sketch (oder einem zweiten mini sketch) die möglichkeit die default werte über ein serielles kommando ins eeprom zu schreiben

- ich würde mit fhem ein ein bsb hex file mit dieser 'leeren' konfiguration ausliefern und aktualisieren. und gegebenenfalls den mini sketch.

- im modul baue ich ein das man direkt aus fhem heraus flashen kann wenn das board lokal oder remote per usb erreichbar ist.

- wenn das setzen der parameter direkt im bsb sketch landet (statt im mini sketch) baue ich auch die konfiguration direkt ins modul ein.

damit könnte man dann das board komplett in betrieb nehmen und updaten ohne selber etwas zu kompilieren

Dann würde ich sagen, wir fangen mit dem Mini-Sketch an, denn bis zum Herbst liegt meine Priorität gerade auf dem Rasenmäher-Projekt. Wenn das dann gut läuft, könnte ich auch schauen, ob man das dann perspektivisch in BSB_LAN komplett mit integriert. Vergrößert aber halt den Speicherbedarf, so dass man mal schauen müsste, ob die Mini-Sketch-Version nicht genauso problemlos läuft und zwei Fliegen mit einer Klappe schlägt. Netmask füge ich dann noch hinzu, kein Problem.

Das mit den zwei Rechnern habe ich auch so (Syno NAS im Keller mit avrdude, an die der Mega angeschlossen ist, kompilieren auf dem MacBook). Nur ist die größte Hürde für viele glaube ich die IDE und die Einstellungen. Wenn man die schon mal gemacht hat, wird man wohl eher auch denS Sketch selber kompilieren, um dann die Konfiguration komplett individuell zu machen (mit Logging etc.). Da das ja bei dieser Variante nicht geht, wird es eher für die Anfänger von Nutzen sein, die auch nicht immer die cutting edge Version haben wollen.

Zitat von: llit am 22 April 2018, 19:05:28
ich bin mir nicht sicher ob ich hier richtig bin oder ob ich einen anderen Thread nutzen sollte. Ich habe euren BSB-LAN Adapter nachgebaut. Als erstes einmal DANKE !!!! ein tolles Projekt.

Hallo Illit, dies ist der Thread für die Modulentwicklung zur BSB-LAN-Anbindung - kannst du deinen Beitrag dorthin https://forum.fhem.de/index.php?topic=29762.0 verschieben? Dann bleibt es für alle Beteiligten übersichtlicher ;)
Danke & Gruß

Hallo Leute,

ich habe heute, da es mir keine Ruhe lies, das ganze noch einmal ausprobiert. Der Ardunio hängt bei mir an einem USB-Ladenetzteil.
Dieses Habe ich gegen ein grosses Netzteil 12V ausgetauscht. Es gab ja wohl das ein oder andere Problem mit der USB Teilen. Leider
brachte das kein Erfolg. Dann habe ich die BSB Software neu aufgespielt Version 0.41  - 18.02.2018. Keine Änderung.
In Fhem habe ich jeweils das BSB-Modul neu definiert.

Version 98_BSB.pm # $Id: 98_BSB.pm 13780 2017-03-23 13:25:41Z justme1968 $

Die Rechte und User der 98_BSB.pm sowie der jquery Dateien hab ich geprüft und sollten passen. Bei der 98_BSB.pm war Besitzer pi und nicht fhem.

Es geht einfach nicht mehr. Am anfang ging es ja mal kurz (halblebig) und ein paar Kategorien kamen.

Hat noch jemand einen Tip ??

Jens

Zitat von: Jewe am 10 Mai 2018, 23:39:13
Der Ardunio hängt bei mir an einem USB-Ladenetzteil.
Dieses Habe ich gegen ein grosses Netzteil 12V ausgetauscht.

12V ist imho schon recht viel - auf Dauer kann ich 9V-Netzteile empfehlen, habe ich bei mir auch nur im Einsatz, kostet ca nen Zehner.

Zitat
Version 98_BSB.pm # $Id: 98_BSB.pm 13780 2017-03-23 13:25:41Z justme1968 $

Die Rechte und User der 98_BSB.pm sowie der jquery Dateien hab ich geprüft und sollten passen. Bei der 98_BSB.pm war Besitzer pi und nicht fhem.

Es geht einfach nicht mehr. Am anfang ging es ja mal kurz (halblebig) und ein paar Kategorien kamen.

Hat noch jemand einen Tip ??

Also geht es dir gerade 'nur' um den Einsatz des Moduls? Adapter und BSB-LAN funktionieren prinzipiell?
In dem Fall würde ich sagen: Abwarten.. Ich habe Andre ein Testsystem geschickt, damit er unabhängig von seiner eigentlichen Heizung entwickeln kann. Wie da derzeit der Stand ist, weiß ich gerade nicht, aber auf jeden Fall kommt da was.. ;)

Hallo zusammen,

erst mal ein ganz grosses Lob an freetz und justme1968. Tolle Arbeit die Ihr hier macht. freetz hat mir vor kurzem die Adapterplatine geschickt die ach auf Anhieb funktioniert. Dank den Ausführungen im Handbuch war die Installation auch für einen Arduino-Laien kein Problem. Und nun klappt auch noch die Integration in FHEM auf Anhieb. Ich bekomme ja fast Angst ;).
Jetzt muss ich gestehen - ich habe nicht jeden Post hier gelesen und vlt. wurde meine Wunsch schon beantwortet:
Settings wären schön. Zum Beispiel das Wochenprogramm oder die Kennlinienveränderung würde ich mir wünschen. Das rumgedrehe an dem Bedienteil der Brötjesteuerung ist einfach nervtötend :)

Danke und weiter so!

Hallo André,

eben ging meine Heizung das erste mal wieder an. Dabei fiel mir dann wieder das BSB-Modul wieder ein.
Und da wollte ich mal vorsichtig anklopfen, konntest du schon etwas weitermachen ?
Leider will das Modul bei mir im Moment ja nicht mehr :-(

Jens

Hallo

ich bekomme die Fehlermeldung BSD module not found

bei

define heizung_control  BSB 192.168.0.1


Danke für Tips

@riker1

Sind den alle Datein installiert?
Stört das Leerzeichen vor "BSB"?

Gruß Gerd

Hallo

welche Dateien muss ich denn genau installieren.
Hatte gedacht BSB ist nun ein Teil von Fhem?

Das Leerzeichen ist es nicht.

Muss ich was aus contrib holen?

Danke Thomas

@riker1

Das Modul ist seit

https://forum.fhem.de/index.php/topic,84381.msg766558.html#msg766558
(https://forum.fhem.de/index.php/topic,84381.msg766558.html#msg766558)
meine ich nicht weiter entwickelt und somit auch noch nicht Bestandteil von FHEM.

Gruß Gerd

Und das ist wirklich schade.

@justme1968: Ich wollte mal fragen, ob die von mir umgesetzten JSON-Funktionen für das Modul so ausreichend sind (wann auch immer Du Zeit hast, es zu Ende zu bringen), da ich inzwischen dabei bin, den Code für den Arduino Due zu portieren, da wir beim Mega inzwischen schon bei einigen Sprachversionen den Speicherplatz überschreiten und der Due uns mehr Luft zum Atmen gibt. Da der Due ja eine ganz andere Plattform ist, würde ich gerne den Mega-Programmteil soweit abschließen, damit auch diese User dann später das Modul ohne Probleme nutzen können, denn darüber hinaus gehende Weiterentwicklungen wird es dann nur noch für den Due-Code geben.

Vielleicht hast Du ja die Möglichkeit, das einmal zu testen und mir Rückmeldung zu geben. Wenn Du Unterstützung bei der Modul-Entwicklung brauchst, könntest Du es ja vielleicht auch in Deinem GitHub-Repository einstellen, dann können auch andere mithelfen?

VG, F.

Hallo,

erstmal vielen Dank für das Modul. Funktioniert wunderbar für die Heizungsparameter.

Kann ich darüber auch DS18B20-Sensoren abfragen? Habe es wie beim Logging mit 20200 und so probiert, aber leider ohne Erfolgt.
Oder funktioniert das nur wenn ich die Werte auf SD logge? Mache ich aktuell nicht.
Falls es über das Modul nicht geht, wie macht ihr das alternativ in FHEM? Über MQTT (noch nicht probiert sie dort aufzunehmen) oder IPWE (da werden sie auf jeden Fall gelistet)?

Besten Dank

@bc-hagbard: Habe gerade zufällig deine Frage gelesen und gemäß dem Motto 'besser spät als nie' antworte ich einfach mal, obwohl es schon länger her ist ;)
Falls es sich also noch nicht erledigt hat: Loggen übers Modul funktioniert m.W. nicht, ebenso wenig wie etliche andere Funktionen, die BSB-LAN bietet. Wenn du also den vollen Funktionsumfang inkl Setzen von Parametern, Passkey-Funktion etc nutzen willst, wirst du auf den Einsatz des Moduls verzichten müssen :(

Was die Abfrage der Tempsensoren angeht: Wie du schon beschrieben hast, gibt's da mehrere Möglichkeiten - dein Geschmack entscheidet ;)
Wirf ansonsten auch nochmal einen Blick ins Handbuch, vielleicht findest du da noch die eine oder andere Anregung.

Btw: Hast du dein System schon 'gemeldet' und Q ausgeführt? Falls nicht, hol' es bitte noch nach und poste es im eigentlichen BSB-LAN-Thread, dieser Wunschliste-Modul-Thread hier ist im Grunde tot, da (zumindest z.Zt.) keine Weiterentwicklung des Moduls stattfindet. Dort kannst du dann auch weitere Fragen bzgl BSB-LAN stellen, falls noch Unklarheiten bestehen ;)

Gruß 

Hallo,

habe dem BSB Modul (98_BSB.pm) mal eine HTTP-Auth Möglichkeit hinzugefügt. Mit zwei Parametern httpAuthPwd und httpAuthUser kann man username/passwort setzen. (welche man in BSB_lan_config.h (USER_PASS[64] / USER_PASS_B64) benutzt hat.
Das ganze ist natürlich alles unverschlüsselt...

Hatte etwas aus den Augen verloren das dass FHEM BSB Modul gar nicht weiter entwickelt wurde...  :-[
Mit der alten 1.x Version von BSB LAN läuft es aber... neue teste ich demnächst mal.

Was wäre denn eine aktuelle Möglichkeit BSB LAN in FEHM einzubinden? JSON per HTTP wäre mir am liebsten (statt MQTT)...  :D

Gruß,
Thomas

Ich habe das hiesige FHEM-Modul lange nicht mehr verwendet und weiß ehrlich gesagt nicht, ob es mit der aktuellen Version noch 100%ig läuft. Ich würde mich eher an HTTPMOD bzw. JSONMOD halten, die beide die Möglichkeit für den Zugriff auf die JSON-Schnittstelle von BSB-LAN ermöglichen. Beim Schreiben müsste man da noch mal genauer schauen. Wenn Du da eine gute Lösung gefunden hast, melde Dich gern, dann nehmen wir das auch ins Handbuch mit auf...