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

[freetz]

@rspecht: Du brauchst kein Tab, wenn Du ein Leerzeichen hast. Und statt des Grad Celsius hast Du das <BR>.
Davon abgesehen, mache ich es genau so wie bei den anderen Parametern auch, nur der Anfang muss halt angepasst werden:
temp\[0\]:[ \t]+([-]?[\d\.]+)

Davon abgesehen habe ich die fehlenden Tabellen-Tags nachgetragen, sollte mit der neuesten Version also auch gehen, wenn man /T ans Ende stellt...

[Schotty]

Nochmal zum Unterschied 6222 & 8330/8332:
6222 zeigt die GERÄTEbetriebsstunden an, also die Zeit, die der Regler/die Hzg prinzipiell angeschaltet war (unabhängig vom Brennerbetrieb!).
8330&8332 zeigen hingegen die BRENNERbetriebsstunden an, also die Zeit, die der Brenner insgesamt lief.
6222 sollte somit also auch immer größer als 8330/8332 sein.

Ich habe mal eben den Taschenrechner bemüht und das kommt mit den Gerätebetriebsstunden (bei meinen erwähnten alten Komplettabfragen) auch hin.

[Schotty]

Und nochmal zum TWW-Push, falls es jemanden interessiert:
Bei Brötje quasi nicht-dokumentiert, findet es sich aber in der Albatros-Doku, s. screenshot und manual im Anhang.

[freetz]

So, da Ihr alle so fleißig wart mit den Rückmeldungen, habe ich jetzt mal die erste Version des JSON-Exports hochgeladen. Mit dem URL-Befehl /J=a,b,c,d... können beliebige Parameter abfragt und im JSON-Format ausgegeben werden. Dabei werden die folgenden Attribute übermittelt:
- Parameter
- Value (->Wert)
- Unit (-> Einheit)
- DataType (0=Zahl, 1=ENUM,... siehe _defs.h)

Das letzte Attribut hilft hoffentlich bei dem geplanten Modul, da man dann schon weiß, wie die Werte ggf. weiter bearbeitet werden müssen.

Vielleicht lässt sich auch das Setzen von Werten per JSON umsetzen. Das Problem ist hier nur der Variablen-Speicher, denn ich muss ja den kompletten HTTP-Request ins RAM laden, und das sind ja nur wenige kB. Mit dem ganzen Overhead ist das schnell erreicht, wenn man mehrere Parameter auf einmal setzen will. Fraglich ist auch, ob eine Begrenzung auf z.B. nur einen Parameter Sinn machen würde oder ob das dann doch der Logik von JSON widersprechen würde.

[rspecht]

temp\[0\]:[ \t]+([-]?[\d\.]+)

Das wars.... hab bei temp vergessen die eckigen Klammern zu Escspen.... damn....
Ich werd alt

Dankefein

[Schotty]

Mir ist gerade noch etwas aufgefallen bzgl 6222:

freetz und numsi haben beide einen LMU7, Gerätefamilie 97, unterschiedliche Gerätevarianten. (In der Auflistung im Handbuch habe ich sie bisher als LMU74 geführt, da freetz bei sich mal nachgesehen hatte. Es gibt noch eine Anlage mit einem LMU75 (Fam.98), aber da habe ich bisher noch keine Rückmeldung bzgl 6220-6228.)

Bei numsi wird unter 6222 Gerätebetriebsstunden ein Wert angezeigt, bei freetz kommt eine error7-Fehlermeldung (dies zwar auch bei einem anderen User mit einem numsi-identischen Regler, aber das kann noch an der verwendeten alten BSB-LAN-Version liegen, da warte ich noch auf Rückmeldung..) Finde ich schonmal sehr merkwürdig.
Bei den restlichen bisher gemeldeten Reglern ist 6222 'existent' und die Werte scheinen auch durchaus plausibel zu sein (wobei ich natürlich das Alter der jeweiligen Anlagen nicht kenne).
Ausnahme: Die LMS14-Regler.
Dazu:
1. Könnte es mit der jüngsten code-Umstellung zu tun haben, dass die LMS14er nicht mehr 'passen'?
2. Könnten diejenigen bzw. gerne auch alle User zum Testen deshalb vielleicht nochmal eine ältere Version flashen und die Ausgabe von 6222 mit der Ausgabe der neuen Version nochmal gegenchecken?

Prinzipiell: Ob die Gerätebetriebsstunden unter 6222 einigermaßen mit dem Anlagenalter passen, kann man in etwa überprüfen, indem man den Wert durch 24 teilt (Std pro Tag) und dann nochmal durch 365 (Tage pro Jahr), dann sollte in etwa das Anlagenalter in Jahren rauskommen (wenn ich mich jetzt nicht fundamental irre  ).

[freetz]

Nein, mit der Umstellung kann das nichts zu tun haben, da es für 6222 nur eine Command ID gibt. Es kann aber sein, dass die Command ID bei diesen Geräten für eine ganz andere Funktion steht und in dem Kontext falsch interpretiert wird. Das könnte man aber nur dann überprüfen, wenn man den Parameter an diesen Geräten direkt aufrufen würde, und das scheint nicht der Fall zu sein. Insofern bleibt das wohl ein Mysterium...

[Schotty]

Hmm, schade eigentlich
Eine Idee, warum 6222 bei dir nicht verfügbar ist? Variantenproblematik..?

[freetz]

Keine Ahnung, Brennerstatus (8009) geht ja auch nicht, ich glaube, nach Logik braucht man da nicht suchen ...

[Schotty]

8009?  Kenn ich auch nicht

[postman]

Moin zusammen,

Code Auswählen Erweitern


8009?  :o Kenn ich auch nicht ::) ;)

also, bei meiner Therme funktioniert der Parameter. Er zeigt mir den Betriebszustand des Brenners an. funktioniert tadellos.
Ich hatte letztens alle Heizkörper runtergeregelt, da ich nicht zu Hause war. Da stand dann im Status "Standby"
Deer Parameter 6222 zeigt weiterhin nur dummes Zeug an
Gruß Uwe

[freetz]

Ach, hat sich erledigt.
Ich muss halt irgendeinen Wert im Set angeben (z.B. set therme Praesenztaste 1234). Auch wenn der schussendlich nicht geschrieben wird.



Nachtrag:
Ich hatte das ein wenig unelegant eingebunden. Besser wäre:
   

Code Auswählen Erweitern

http://hostname/S710=$val

So kann ich dann wie folgt umschalten:

Reduziert:

Code Auswählen Erweitern

set therme Praesenztaste 1

Komfort:

Code Auswählen Erweitern

set therme Praesenztaste 0

Sehr seltsam, so mache ich seit Anbeginn und habe es bei mir mit

Code Auswählen Erweitern

http://192.168.1.50/xxxx/S710=$val
eingebunden. Nun bekomme ich auch, wie ich jetzt erst sehe, seit etwa 10. Februar den Fehler "not numeric", bzw. im Logfile die Meldung, dass der Request einen Timeout bekommt (aber nur der mit den Set-Befehlen, die anderen gehen problemlos durch).
Das Setzen über die Webschnittstelle geht ohne Probleme.

[freetz]

Seltsam, nun geht es nach einem Neustart von FHEM wieder mit dem Setzen - Und das timeout Problem hat sich dadurch gelöst, dass ich den Wert von 5 auf 10 Sekunden erhöht habe. Dabei dauert das Setzen per URL von dem gleichen Rechner aus per wget nur eine, manchmal 2 Sekunden. Aber wahrscheinlich reißen die drei Werte, die ich dabei setze in der Summe die fünf Sekunden.
Seltsam nur, dass das beim Lesen der Parameter nie ein Problem war, da hole ich mit einer URL etwa 10 Werte, und die bekommt er in 3-4 Sekunden.
@Schotty: Vielleicht noch ein Aspekt für die FAQ, dass man bei Timeout-Problemen den Timeout-Wert in FHEM so bemessen sollte, dass pro Parameter zwei Sekunden angesetzt werden?

[Schotty]

@Schotty: Vielleicht noch ein Aspekt für die FAQ, dass man bei Timeout-Problemen den Timeout-Wert in FHEM so bemessen sollte, dass pro Parameter zwei Sekunden angesetzt werden?

Yupp, wird gemacht. Bezieht sich dann aber nur auf das Setzen, korrekt?

[freetz]

Ich würde es auch auf das Abfragen beziehen, auch wenn man da weniger ansetzen müsste. Man könnte ja sagen, dass man pro Setz-Befehl 2 und pro Abfragebefehl eine Sekunde ansetzen sollte - ist auch insofern logisch, als dass beim Setzen ja anschließend noch eine Abfrage gemacht wird.