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

[gero]

Für die Auswertung wäre es sehr interessant, bei den Werten "Außentemperatur" und "Brennermodulation" nicht (nur) die jeweiligen momentanen Werte abzufragen, sondern den Arduino den Mittelwert der letzten 24h errechnen zu lassen. Dazu würde es sicherlich reichen, die beiden Werte (bei meiner Thision 8326 für Modulation und 8700 für Außentemperatur) z.B. alle fünf Minuten zu pollen und daraus dann den jeweiligen Mittelwert zu bilden (wären bei 24h also pro Parameter 288 Werte).
Wenn man diese beiden Mittelwerte dann über eine URL abrufen könnte, wäre es deutlich einfacher, die Heizung zu optimieren, weil ich dann die Beziehung zwischen Durchschnittstemperatur und Durchschnittsbrennermodulation ins Verhältnis setzen kann, um zu sehen, welche Wirkung die Einstellungen haben.

In Perl würde ich das so umsetzen, dass ich ein Array mit 288 Feldern habe, bei dem ich alle 5 Minuten das nächste fülle und bei Index 289 dann wieder auf 1 (bzw. 0) springe.

Gero, ließe sich das ohne allzu großen Aufwand auch in C umsetzen? Ich scheitere immer daran, die Werte entsprechend zu pollen und dann die Variablen richtig zu typisieren - da bin ich bei Perl einfach zu nachlässig geworden .

Ich glaube, dass auch andere von dieser Funktion profitieren würden, gerade weil es ja in den letzten Posts auch um das Verhalten der Heizung ging.

Hallo freetz,

meiner Meinung nach sollten solche Analysen in fhem umgesetzt werden. Was spricht dagegen, dass fhem alle 5 Minuten die Werte pollt?
Es steht natürlich jedem frei den Sketch nach seinen Wünschen zu erweitern und ich bin auch gerne dazu bereit hierbei Hilfe zu leisten. Allerdings können wir nicht jeden Spezialwunsch im Sketch aufnehmen, da der Atmega (wie du schon festgestellt hast) begrenzte Resourcen hat.

[gero]

Ok, es ging nun doch einfacher, als ich gedacht hatte und ich habe es nun doch selber geschafft, das so umzusetzen. Für den Fall, dass es auch für andere interessant sein könnte, hier die Code-Snippets, die ich hinzugefügt habe. Da ich momentan noch mit der Version 0.12 arbeite, ist es so vielleicht einfacher, als wenn ich den kompletten Sketch hochlade:

In der Global-Sektion:

Code Auswählen Erweitern

double logAvgTemp[289];
byte logAvgModulation[289];
word AvgIndex = 0;
word AnzIndexValues = 0;
double AvgTemp = 0;
byte AvgModulation = 0;
static unsigned long nextSwitchTime = millis();

In der Loop-Funktion:

Code Auswählen Erweitern

  if (nextSwitchTime < millis() ) {
    logAvgTemp[AvgIndex]=strtod(query(8700,8700,1),NULL);
    logAvgModulation[AvgIndex]=strtod(query(8326,8326,1),NULL);
    AvgIndex++;
    AnzIndexValues++;
    if (AvgIndex > 287) {AvgIndex = 0;}
    if (AnzIndexValues > 288) {AnzIndexValues = 288;}
    nextSwitchTime = millis() + 300000;
  }

In der IPWE-Extension (darüber erfolgt die Ausgabe), vor der Zeile #ifdef ONEWIRE_SENSORS:

Code Auswählen Erweitern

  AvgTemp = 0;
  AvgModulation = 0;

  if (AnzIndexValues > 0) {
    for (i=0; i<AnzIndexValues; i++) {
      AvgTemp = AvgTemp + logAvgTemp[i];
      AvgModulation = AvgModulation + logAvgModulation[i];
      client.println(logAvgModulation[i]);
    }
    AvgTemp = AvgTemp / AnzIndexValues;
    AvgModulation = AvgModulation / AnzIndexValues;
  }

  client.print(F("<tr><td>T<br></td><td>"));
  client.print(sensor_anz+2);
  client.print(F("<br></td><td>"));
  client.print(F("AvgTemp"));
  client.print(F("<br></td><td>"));
  client.print(AvgTemp);
  client.print(F("<br></td><td>0<br></td><td>0<br></td><td>0<br></td></tr>"));

  client.print(F("<tr><td>T<br></td><td>"));
  client.print(sensor_anz+3);
  client.print(F("<br></td><td>"));
  client.print(F("AvgModulation"));
  client.print(F("<br></td><td>"));
  client.print(AvgModulation);
  client.print(F("<br></td><td>0<br></td><td>0<br></td><td>0<br></td></tr>"));


Für die Modulation wäre eine etwas dichtere Überwachung sicher nicht schlecht, weil man dann etwaige Spikes oder bei häufiger Taktung genauere Ergebnisse bekommen würde, aber mehr macht der Speicher des Arduino Mega nicht mit. Ich habe daher schon bei der Modulation auf den Variablen-Typ "Word" gesetzt, da der nur 2 statt 4 Byte benötigt. Obwohl der Speicher auch mit "Double" nur zu 91% belegt war, kam es da zu seltsamen Verhaltensweisen. Jetzt, mit etwas mehr Puffer (81%) scheint es recht stabil zu laufen.

Wie äußert sich das "seltsame Verhalten"?
Ich habe deinen Code jetzt nur kurz überflogen. Dabei ist mir folgendes aufgefallen:
Bei der Aufsummierung der Modulationswerte wirst du sehr wahrscheinlich einen Überlauf bekommen:

Code Auswählen Erweitern

AvgModulation = AvgModulation + logAvgModulation[i];


Du solltest für AvgModulation etwas mehr als ein byte spendieren, z.B. ein unsigned int sollte bei den Prozentwerten reichen  (mit unsigned long liegst du auf der sicheren Seite).

Gruß,
Gero

[freetz]

Hallo Gero,

ja, von FHEM aus betrachtet macht es sicher keinen großen Sinn, die Aufsummierung im Arduino machen zu lassen. Da ich aber die Daten über ein externes Programm grafisch darstellen lasse (MaxStats, das mit MaxBuddy zusammen läuft), und es am Ende kein großer Aufwand war, habe ich es dort gelassen. Letztlich ist für Programmcode ja noch genügend Platz vorhanden, nur sehr viel mehr Variablen dürften in Zukunft nicht mehr hinzu kommen. Jenachdem, was Du mit dem Sketch noch vor hast, könnte das natürlich ein zwingender Grund sein, solche Funktionen auch bei mir in Zukunft wieder auszulagern.

Vielen Dank für den Hinweis mit dem Überlauf, das stimmt natürlich, wie ich jetzt auch gerade nach der Nacht sehen durfte . Das "seltsame Verhalten" war aber, dass bei einer Variablen-Speicherbelegung von 91% der Aufruf der ipwe.cgi-Funktion im Log mit "invalid passkey" quittiert wurde, wobei dort ja gar keine Passkey-Überprüfung stattfinden sollte. Nachdem ich dann die Variablen-Typisierung von LogAvgModulation von double auf byte reduziert hatte, war das Problem verschwunden. Seltsam, wie gesagt, aber vielleicht haben sich dann zur Laufzeit doch Speicherbereiche überschnitten?

Viele Grüße

F.

[FunkOdyssey]

Tag, ich hab gerade mal eine ganz andere Frage.

Ich habe plötzlich sehr viele HTTPMOD-Fehlermeldungen im Log stehen:

Code Auswählen Erweitern

2016.04.11 08:59:12 3: broetje: Read callback: request type was update retry 0,
Header: HTTP/1.1 200 OK
Content-Type: text/html, body empty,
Error: connect to to http://xxx.xxx.xxxxxx:80 timed out

Dies war bis vor kurzem nicht. Es hat sich aber auch viel geändert, so dass die Fehlerquelle schlecht einzugrenzen ist:
- Netztteil getauscht (iPhone-Netzteil angeschlossen)
- BSB auf 0.14 aktualisiert
- FHEM Updates
- Shield getauscht (war bei anderen Shields aber auch)

Hat jemand ein Tipp woher das kommen könnte?
Kann so etwas evtl. vom zu schwachen Netzteil kommen?

[Schotty]

Hi,
bei mir findet FHEM hin und wieder auch nichts, sprich, HTTPMOD findet quasi keinen Webseiteninhalt, in dem es suchen könnte (kann man bei dem entspr. Device dann oben im großen Feld sehen, wo normalerweise der Seiteninhalt angezeigt wird). War aber schon immer so, und derzeit ist mein FHEM-Raspi nicht in Betrieb, ich kann also keine Aussage zur v0.14 und FHEM-Updates machen. 
Woran es liegt? Leider auch keine Ahnung..
Gruß

[frank]

das passiert bei mir zb, wenn 2 connections gleichzeitig angefordert werden. eventuell mal das timeout attribut erhöhen. nach einem timeout error im reading LAST_ERROR löst bei mir ein notify nach einem sleep einen weiteren request aus. allerdings nur 3 versuche nacheinander, weil sonst bereits bald wieder der normale zyklus in die quere kommt.

[Schotty]

Hm, die timeouts hatte ich schon entsprechend erhöht, hin und wieder trat es trotzdem auf. Aber du hast sicherlich recht, und es werden sich trotzdem zwei Abfragen in die Quere gekommen sein. Ich weiß aber leider auch nicht mehr, ob bei mir dann ein timeout-error angezeigt wurde. Ich meine, es war einfach eine leere Seite. Aber danke für den Tipp, ich werde es mal im Auge behalten, wenn der Raspi wieder in Betrieb ist. Da ich mangels (Einarbeitungs-)Zeit die db-logs noch nicht eingerichtet habe, nutze ich momentan bei Bedarf einfach nur die direkte Abfrage des Ardu über Geros Webinterface, und das funzt auch reibungslos..

[FunkOdyssey]

Hmm, ich habe gerade mal einen Blick auf TRIGGERTIME geworfen und festgestellt, dass alle (fünf) HTTPMODs quasi gleichzeitig starten.
Ich suche gerade nach eine Möglichkeit, eine Art Delay einzustellen, um die ein wenig zeitverzögert zu starten.

[freetz]

Hallo Gero,

eine kurze Nachfrage noch zu den Möglichkeiten von FHEM:

meiner Meinung nach sollten solche Analysen in fhem umgesetzt werden. Was spricht dagegen, dass fhem alle 5 Minuten die Werte pollt?
Es steht natürlich jedem frei den Sketch nach seinen Wünschen zu erweitern und ich bin auch gerne dazu bereit hierbei Hilfe zu leisten. Allerdings können wir nicht jeden Spezialwunsch im Sketch aufnehmen, da der Atmega (wie du schon festgestellt hast) begrenzte Resourcen hat.

Mir fiel vorhin noch auf, dass es ja nicht reichen würde, dass FHEM alle 5 Minuten die Werte pollt (das wäre dann wirklich eine sinnlose Funktion), sondern dass die Werte dann ja noch in ein "rotierendes" Array geschrieben, und daraus dann die Mittelwerte ermittelt werden müssten, um auf den jeweiligen 24h Durchschnitt zu kommen. Wenn das in FHEM geht, dann bräuchte man die Funktion wirklich nicht einzubinden (und dann würde ich vielleicht auch mal intensiver mit dem Gedanken spielen, mein ganzes Setup auf FHEM zu übertragen).
Aber wenn das nicht ohne weiteres möglich wäre, könnte eine Einbindung dieser Funktion "an der Quelle" vielleicht doch ganz sinnvoll sein, zumal die Auswertung über das IPWE-Modul bei FHEM dann ebenfalls einfach möglich wäre.

Aber nur meine 0,02€...

F.

[Schotty]

Moin freetz,
nur mal so interessehalber: Was versprichst du dir eigtl. hinsichtlich möglicher Optimierungen von dem Verhältnis zw. durchschnittlicher AT und Brennermodulation? Ich habe zwar keine Gastherme, nur einen 2stufigen Öler, aber verstehen würd ich's trotzdem gerne..
Gruß

[frank]

Hmm, ich habe gerade mal einen Blick auf TRIGGERTIME geworfen und festgestellt, dass alle (fünf) HTTPMODs quasi gleichzeitig starten.
Ich suche gerade nach eine Möglichkeit, eine Art Delay einzustellen, um die ein wenig zeitverzögert zu starten.

warum 5 stück?
das geht doch bestimmt auch mit einem für alles.

[freetz]

nur mal so interessehalber: Was versprichst du dir eigtl. hinsichtlich möglicher Optimierungen von dem Verhältnis zw. durchschnittlicher AT und Brennermodulation? Ich habe zwar keine Gastherme, nur einen 2stufigen Öler, aber verstehen würd ich's trotzdem gerne..
Gruß

Bei einem Öler ist der Effekt vielleicht nicht ganz so ausgeprägt, aber meine Thision kann ja stufenlos modulieren, und das eben in Abhängigkeit von der Außentemperatur verbunden mit der Heizkurve und Parallelverschiebung. Geros Device hat es mir bisher ja schon ermöglicht, die Brenneraktivität längerfristig zu beobachten, aber nun war es diesen Winter so, dass ich dachte, ich hätte eine gute Einstellung der Heizkurve und Verschiebung gefunden, die aber bei "mittelkalten" Tagen (knapp unter null) gar nicht gepasst hat. Beim Nachjustieren war ich dann wieder öfter über's Ziel hinaus geschossen, weil es dann wieder mal einen halben Tag zu warm war etc.

Wenn ich jetzt zwei Kurven habe, bei denen jeder Wert dem 24h-Mittel entspricht, dann kann ich quasi Punkt-für-Punkt sehen, ob der Brenner für eine bestimmte Mittel-Temperatur optimal eingestellt ist und weiß dann besser, ob ich doch eher an der Heizkurve oder an der Verschiebung etwas ändern muss oder am Ende doch sogar noch bei solchen Parametern wie der Gebäudekonstante drehen muss.

Ein anderes Einsatzgebiet ist bei mir, zu schauen, ob bzw. bei welchen Temperaturen eine Nachtabsenkung Sinn macht - auch da kann man ja nur sinnvoll Vergleiche anstellen, wenn die Temperaturen Tags und Nachts relativ ähnlich waren.

Das sind jetzt sicher keine riesigen Effekte, aber so wie mir es schien, vielleicht doch noch mal 5% oder so. Und das ist bei einem mäßig gedämmten 1960er Jahre Haus dann doch die Mühe wert ...

F.

[FunkOdyssey]

warum 5 stück?
das geht doch bestimmt auch mit einem für alles.

Das würde sicherlich funktionieren. Nur wollte ich recht datenlastige, weniger wichtige Parameter (Fehlercode) weniger oft auslesen. Es ist bei mir also größtenteils eine Frage des Intervalls und der einfacheren Pflege. Ich wäre sonst bei 40 Readings. Und das macht kein Spaß in HTTPMOD.

[frank]

Nur wollte ich recht datenlastige, weniger wichtige Parameter (Fehlercode) weniger oft auslesen.

das sollte trotzdem funktionieren.
unterschiedliche getxx definieren und die weniger oft zu pollenden mit einem getxxpolldelay verzögern.

[frank]

@freetz
die mittelwertbildung sollte in fhem mindestens genauso einfach sein.
schau dir mal das attr event-aggregator an, oder das modul statistics.