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

[tetzlav]

BTW, ich wünsch mir ne Möglichkeit mehrere Parameter parallel mit einem wget/curl Aufruf zu setzen. So nach der Art

Code Auswählen Erweitern

wget -qO- http://192.168.178.8/S710=21.0,I10000=20.5,I10003=13.2

Ich bin gerade dabei bsb_lan in iobroker zu integrieren und kann dank systeminfo-adapter und JSON die Parameterabfragen alle in einen Rutsch abfragen.

Code Auswählen Erweitern

  "native": {
    "si": {
      "name": "Therme.[name/value]",
      "type": "web",
      "source": "http://192.168.178.8/JQ=710,750,6100,8009,8308,8310,8314,8323,8326,8331,8700,8703,8704,8740,8744,8750,8830,8950,9009",
      "regexp": "[?(@.name, @.value)]",
      "conv": "json",
      "role": "number",
      "write": "",
      "sched": "*/1 * * * *",
      "id": {
        "pre": "Therme.",
        "post": "",
        "mid": "name/value",
        "name": "name",
        "value": "value"
      }
    }

Aber beim Setzen von Werten muss ich mom. für jeden Parameter ein eigenes exec(wget) aufrufen und die Webserveranfrage kommt sich u.U. mit den parallen Abfragen anderen Instanzen in die Quere und endet aufgrund begrenzter Ressourcen des BSB_LAN hinundwieder in einem "Connection refused".

Kann man eigentlich auch die INF-Telegramme I1000X via JSON setzen? Und wie wäre dann die Syntax?

Code Auswählen Erweitern

curl -H "Content-Type: application/json" -X POST -d '{"Parameter":"10003", "Value":"13.2", "Type":"1"}' http://192.168.178.8/JS

Was ist eigentlich ressourcenschonender? Setzen via /S710=21.0 oder generell abfragen/setzen via JSON?

Wenn ich mit dem Haus fertig bin und die Kinder wieder weniger Aufmerksamkeit fordern und ich ganz viel Langeweile haben sollte, dann schreib ich mal einen iobroker Adapter für  BSB_LAN...

[freetz]

Nein, das Setzen mehrerer Parameter geht nicht, bisher war es ja auch meist nur die Raumtemperatur, die die Leute regelmäßig gesetzt haben, dazu kommt jetzt bei einigen Geräten die Möglichkeit, die Außentemperatur zu setzen. Den Sollwert ständig zu übermitteln ist eher ungewöhnlich.

Zu einem Timeout oder Connection Refused sollte es aber eigentlich nur dann kommen, wenn Du wirklich viele Parameter in kurzen Zeiträumen abfragst, und das ist dann auch eher ein Problem für das, was sonst auf dem Bus nicht durchkommen könnte. Das Timeout bei wget und curl solltest Du einstellen können, und wenn die Abfrage dann durch ist, kommen auch diese noch zum Zug, sehe ich bei mir jedenfalls regelmäßig. Ansonsten die Abfragen so timen, dass die Schreibvorgänge vor den Lesevorgägen ablaufen.

Das Setzen von INF-Parametern sollte so funktionieren, wie Du es beschrieben hast, also mit dem Attribut "Type" und dem Wert "1".
"Ressourcenschonender" wäre vermutlich das Setzen via "/S", weil da weniger Strings analysiert werden müssen, aber im Endeffekt macht das vermutlich keinen merkbaren Unterschied.

[Schotty]

... Ich habe daher diesen Test in /Q mit eingebaut. "Außentemperatur (10003)" ist der Eintrag, um den es dann geht. Wenn hier ein Wert zurück gemeldet wird, unterstützt die Steuerung die Funktion. Wenn nicht, dann sehr wahrscheinlich nicht. ...

Prinzipiell eine gute Idee, aber in Anbetracht der erwähnten Speicherknappheit m.E. eigtl nicht nötig: Wir wissen ja nun, dass es nur mit RVS und LMS-Reglern zu funktionieren scheint.
Zur Bestätigung muss eigtl nur noch jemand mit nem LMS14er den Test durchführen, dazu reicht dann ja auch einmal das manuelle Abrufen von /10003. Beim SSR (RVS63) und dem aktuelleren RVS43.245 wird es mit 99,9%iger Sicherheit auch funktionieren - den SSR teste ich selber und der RVS43.245 ist die aktuellere Version meines Reglers, an dem ich es schon getestet habe. RVS21 der Wärmepumpen sollte es auch können, aber das kann ich sonst auch im Einzelfall nochmal anfragen. Ein LMU75 als Test, ob es auch dort nicht funktioniert, wäre noch nice to have, aber das Ergebnis ist eigtl schon klar.
Bevor wir jetzt auf Rückmeldungen von /Q der entspr Reglertypen warten, kann ich sonst lieber gezielt entspr User anschreiben, dass sie bitte einmal /10003 ausführen.
Aber ich denke, im Grunde ist sogar das relativ unnötig, denn das Feature ist ja nun doch recht speziell (ich denke, nur ein kleiner Prozentsatz der User wird die Funktion nutzen) und wer es denn wirklich nutzen will, kann/wird/sollte es vorher sowieso einmal testen, ob es funktioniert oder nicht. Die entspr Hinweise kommen sowieso ins entspr Kapitel im Handbuch.

[freetz]

Ich denke schon, dass das Sinn macht, um wirklich Klarheit zu haben und nicht nur zu vermuten. Wir haben ja schon so einige Überraschungen erlebt, was Funktionalitäten angelangt. Momentan passt es vom Speicher her noch, und wenn wir alle (bisher bekannten) Steuerungen geprüft haben und keine Anomalien aufgefallen sind, kann man das ja auch wieder rausnehmen. Am Ende könnte es doch für mehr User relevant sein, insbesondere bei Neubauten, wenn man dann keine Kabel nach draußen legen muss usw.
Ich selber habe ja gar nichts davon, aber mir geht es auch um das Vervollständigen des Kenntnisstandes, also was geht (warum) und was nicht (warum...

[Schotty]

Ich denke schon, dass das Sinn macht, um wirklich Klarheit zu haben und nicht nur zu vermuten.

Deswegen meinte ich ja, dass ich sonst auch gezielt ein paar ausgewählte User anschreiben kann, um die bisher unklaren Regler zu testen. Würde uns vermutlich schneller zum Ziel führen Gefühlt sind die meisten neuen Systeme i.d.R. sowieso Gaser mit LMS15 oder WPs mit RVS21..

[Schotty]

Achso: Welche Variante ist/wird denn nun eigtl die 'finale' bzw die empfehlenswerte Version - mit oder ohne !127er BC-Zusatz?

[freetz]

Das ist letztlich egal - ich würde im Handbuch die ohne !127 aufführen, um die "Frischlinge" nicht zu verwirren. Der Test über /Q läuft auch ohne !127, so dass auch das der weiteren Erkenntnisfindung dient.
Mein Hintergedanke, das in /Q einzubetten war übrigens auch, dass wir damit noch mal Leute dazu bekommen, uns eine aktualisierte /Q zu schicken, denn es kann gut sein, dass in der Zwischenzeit wieder Parameter hinzugekommen sind, die man bei anderen Gerätefamilien aktualisieren müsste...

[Schotty]

Okidoki, dann werde ich es so machen.

Mein Hintergedanke, das in /Q einzubetten war übrigens auch, dass wir damit noch mal Leute dazu bekommen, uns eine aktualisierte /Q zu schicken,

Das dachte ich mir schon, leider ist es erfahrungsgemäß aber ja eher so, dass die Leute hier nicht mehr wirklich mitlesen, wenn es läuft. Aber alles gut, war ja nur so ein Gedanke von mir, da du die Speicherknappheit des Öfteren erwähnt hast. Ich werde trotzdem mal einige User anschreiben, damit wir da schnell(er) Klarheit bekommen - und wenn /10003 reicht, um es herauszufinden (und das Abklemmen des Fühlers mit reellem Info-Befehl /I10003=xx nicht nötig ist), dann ist das ja auch user-seitig schnell getan..

[tetzlav]

Nein, das Setzen mehrerer Parameter geht nicht, bisher war es ja auch meist nur die Raumtemperatur, die die Leute regelmäßig gesetzt haben, dazu kommt jetzt bei einigen Geräten die Möglichkeit, die Außentemperatur zu setzen. Den Sollwert ständig zu übermitteln ist eher ungewöhnlich.

Ich baue gerade deine "Dynamische Soll-Ist-Temperaturübermittlung an Heizungstherme" für/in iobroker nach und dort übermittele ich eben die drei Temperaturen 710, 10000 und 10003 minütlich (wie die Raumgeräte bzw. der RF-AT-Sensor).

Gleichzeit habe ich aber auch minütlich http://192.168.178.8/JQ=710,750,6100,8009,8308,8310,8314,8323,8326,8331,8700,8703,8704,8740,8744,8750,8830,8950,9009 laufen.

Zu einem Timeout oder Connection Refused sollte es aber eigentlich nur dann kommen, wenn Du wirklich viele Parameter in kurzen Zeiträumen abfragst, und das ist dann auch eher ein Problem für das, was sonst auf dem Bus nicht durchkommen könnte. Das Timeout bei wget und curl solltest Du einstellen können, und wenn die Abfrage dann durch ist, kommen auch diese noch zum Zug, sehe ich bei mir jedenfalls regelmäßig. Ansonsten die Abfragen so timen, dass die Schreibvorgänge vor den Lesevorgägen ablaufen.

Ich kann aber das genaue Timing der Abfrage durch den iobroker Adapter nicht wirklich beinflussen. Deßhalb möchte ich wenigstens beim Setzen der Parameter die Aufrufe minimieren.

Das Setzen von INF-Parametern sollte so funktionieren, wie Du es beschrieben hast, also mit dem Attribut "Type" und dem Wert "1".
"Ressourcenschonender" wäre vermutlich das Setzen via "/S", weil da weniger Strings analysiert werden müssen, aber im Endeffekt macht das vermutlich keinen merkbaren Unterschied.

Das funktioniert leider nicht, 8740 und 8700 bleiben unbeeindruckt, die RT und AT werden nach 10min "---". Der Aufruf von curl beim Setzen von 10003 via JSON dauert auch länger als bei 870 oder 10000.

Code Auswählen Erweitern

$ curl -H "Content-Type: application/json" -X POST -d '{"Parameter":"10000", "Value":"20.9", "Type":"1"}' http://192.168.178.8/JS
{
  "10000": {
    "status": 0
  }
}
$ curl -H "Content-Type: application/json" -X POST -d '{"Parameter":"10003", "Value":"13.2", "Type":"1"}' http://192.168.178.8/JS
{
  "10003": {
    "status": 0
  }
}
$ wget http://192.168.178.8/JQ=8740,8700 -qO-
{
  "8740": {
    "name": "Raumtemperatur 1",
    "value": "---",
    "unit": "°C",
    "desc": "",
    "dataType": 0
  },
  "8700": {
    "name": "Außentemperatur",
    "value": "---",
    "unit": "°C",
    "desc": "",
    "dataType": 0
  }
}


[freetz]

Sorry, Type muss "0" für INF sein und "1" für SET...

Was das Timing angeht, ist das natürlich blöd, wenn iobroker das nicht kann. Bei FHEM kann ich solche Aspekte sehr genau beeinflussen. Aber wie gesagt, ich selber mache das noch nicht mal und Timeouts kommen bei mir bei ca. 10 Parametern auch nicht. Wenn Du die Abfrage der Parameter auf 2 Minuten setzt, müsste aber selbst bei Timeouts jeder zweite Schreibvorgang ohne Probleme durchgehen.

Und es wäre auch die Frage, ob Du alle diese Parameter wirklich mit minütlicher Genauigkeit brauchst. Ich glaube kaum, dass sich die Parameter 750, 6100, 8331 (nur bei extrem schlechter Einstellung der Therme), 8703, 8704 und 9009 minütlich ändern. Da wären fünf Minuten sicher mehr als ausreichend...

[Schotty]

..dort übermittele ich eben die drei Temperaturen 710, 10000 und 10003 minütlich (wie die Raumgeräte bzw. der RF-AT-Sensor).

Gleichzeit habe ich aber auch minütlich http://192.168.178.8/JQ=710,750,6100,8009,8308,8310,8314,8323,8326,8331,8700,8703,8704,8740,8744,8750,8830,8950,9009 laufen.

Nur als Hinweis: Bei der Menge der abzufragenden und hinzu noch zu setzenden Parametern in dem recht kurzen Intervall kann es passieren, dass sich die Abfragen mal überschneiden und/oder der Regler oder BSB-LAN nicht hinterher kommt. Kann also passieren, dass du da hin und wieder keine vernünftigen Readings bekommst und/oder sich sogar mal BSB-LAN 'aufhängt'. Letzteres ist vermutlich nicht der richtige Ausdruck, aber wenn eine Abfrage läuft und dann eine neue kommt, führte es bei mir in der Vergangenheit bei verschiedenen Testszenarien hin und wieder mal dazu, dass ich den Ardu neu starten musste, damit alles wieder vernünftig funzte. Auch der Regler kann nur eins nach dem anderen Abarbeiten.

[tetzlav]

Sorry, Type muss "0" für INF sein und "1" für SET...

Ich muss mich entschuldigen, steht ja alles im Handbuch. Mit "0" funktioniert es

Was das Timing angeht, ist das natürlich blöd, wenn iobroker das nicht kann. Bei FHEM kann ich solche Aspekte sehr genau beeinflussen. Aber wie gesagt, ich selber mache das noch nicht mal und Timeouts kommen bei mir bei ca. 10 Parametern auch nicht. Wenn Du die Abfrage der Parameter auf 2 Minuten setzt, müsste aber selbst bei Timeouts jeder zweite Schreibvorgang ohne Probleme durchgehen.

Dieser iobroker Adapter bietet es m.K.n. nicht an, bzw. bietet nur timer in cron-angelehnter Syntax und kein scheduler, womit ich es mit anderen Instanzen synchronisieren kann.

Und es wäre auch die Frage, ob Du alle diese Parameter wirklich mit minütlicher Genauigkeit brauchst. Ich glaube kaum, dass sich die Parameter 750, 6100, 8331 (nur bei extrem schlechter Einstellung der Therme), 8703, 8704 und 9009 minütlich ändern. Da wären fünf Minuten sicher mehr als ausreichend...

Sicherlich kann man die Timer vergrößern und alles kommt noch jede Information rechtzeitig an. Nach dem Motto "jeder zweite kommt schon an" mit provozierte Fehlermeldungen sind aber nicht "schön" und m.M.n. auch irgendwie "schlechter Stil". Mir geht es ja auch um Optimierung.

Ich habe u.a. eben das Problem, dass die Therme momentan ganz stark taktet (>100/d) und zwischendurch mal unter einer Minute an und wieder ausgeht. Ich logge gerade ziemlich viel mit um zu verstehen was da schief läuft bzw. was ich einstellen muss. Es gibt aber auch eine so große Vielzahl von Parametern, die auch noch mehr oder weniger gut dokumentiert sind. 

[freetz]

Naja, "unschön" wird es irgendwann bei zu großer Anzahl von Parametern immer. Wegen der Speicherplatzbegrenzung versuche ich nicht-essentielle Funktionen (die dauerhaft im Code bleiben sollen) zu vermeiden.
Bei einer cron-kompatiblen Syntax kannst Du aber sehr wohl die Startzeiten verschieben:
0/2 * * * * -> alle zwei Minuten, beginnend bei Minute 0 einer jeden Stunde
1/2 * * * * -> alle zwei Minuten, beginnend bei Minute 1 einer jeden Stunde

Hat es denn überhaupt schon Timeouts gegeben oder befürchtest Du diese nur?

[Schotty]

Ich muss mich entschuldigen, steht ja alles im Handbuch.

Ich habe u.a. eben das Problem, dass die Therme momentan ganz stark taktet (>100/d) und zwischendurch mal unter einer Minute an und wieder ausgeht. Ich logge gerade ziemlich viel mit um zu verstehen was da schief läuft bzw. was ich einstellen muss. Es gibt aber auch eine so große Vielzahl von Parametern, die auch noch mehr oder weniger gut dokumentiert sind. 

Klassisches Problem in der Übergangszeit. Abgesehen von kessel- bzw. reglerseitigen Einstellungen wie bspw. Parallelverschiebung (in der Übergangszeit einzustellen) und Steilheit (in der kalten Jahreszeit zu ermitteln) der Heizungskennlinie - hast du mal die Einstellung deiner Heizkreispumpe überprüft? Wenn die auf 'ECO' steht, dann kann es gut sein, dass die Wärme nicht schnell genug abtransportiert wird und es dadurch zum übermäßigen Takten kommt..

[tetzlav]

Naja, "unschön" wird es irgendwann bei zu großer Anzahl von Parametern immer. Wegen der Speicherplatzbegrenzung versuche ich nicht-essentielle Funktionen (die dauerhaft im Code bleiben sollen) zu vermeiden.
Bei einer cron-kompatiblen Syntax kannst Du aber sehr wohl die Startzeiten verschieben:
0/2 * * * * -> alle zwei Minuten, beginnend bei Minute 0 einer jeden Stunde
1/2 * * * * -> alle zwei Minuten, beginnend bei Minute 1 einer jeden Stunde

Ich habe gerade gesehen, dass der node-scheduler auch Sekunden unterstützt. Damit starte ich jetzt die settings jetzt am Anfangs jeder Minute und die langen Readings haben dann den Rest der Minute Zeit. Danke für den Hinweis!

Hat es denn überhaupt schon Timeouts gegeben oder befürchtest Du diese nur?

Ja, aber Anfangs habe ich einen eigenen Timer verwendet und je nachdem wann ich das script gestartet hab, kam es zu Überschneidungen.