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

[fabulous]

Moin,

das ist mir klar.
Ich habe bisher noch nicht mit FHEM oder mit Perl gearbeitet.
Es ist für mich wesentlich einfacher, 30 Zeilen C-Code zu programmieren als mich dort einzuarbeiten.

Gruß
Fabian

[freetz]

Na, wenn Du's in 30 Zeilen schaffst, kannst Du gerne einen Pull-Request absetzen, dann binde ich das gerne ein. Ansonsten musst Du ja bei jedem Update neu schauen, dass Du es entsprechend einbindest...

[Maista]

Moin.
Das Modul von justme1968 funktioniert doch bestens.
Dort gibt man an welche Daten man haben will, erzeugt noch ein Filelog und gut ist.
Das Anfrageintervall muss man allerdings, wenn 30s zu niedrig, selbst im Source anpassen.

Gruß Gerd

[TV-age]

 @Freetz: Ja! zuerst kann ich alle Werte abrufen, dann /T (hier kommen sie Senoren), dann geht die Abfrage der Werte nicht mehr. Auch nach stromlos und Wiederanlauf! Die Abfrage "Heizungsfunktion","Einstellungen",... usw, funktionieren

Was ist ein "SerMo-Log" ? Wie kann ich den Logger aktivieren?

[freetz]

Steht alles im Handbuch...

[TV-age]

Okay -schaun wir mal 

[freetz]

Also ich habe zwar wie geasgt keine Sensoren dran hängen, aber eben einmal fest eingetragen, dass ich einen hätte. Da bekomme ich dann natürlich wirre Werte, aber an sich funtioniert es alles wie gewollt.
Kannst Du mal folgendes aufrufen:
http://<ip>/8700/T/8700/T/8700
Da müsste dann im Wechsel die AT und dann die Sensoren ausgegeben werden. Oder geht es da schon nur beim ersten Mal gut?
Ansonsten wie gesagt einen Mitschnitt des Seriellen Monitors hier posten...

[loetmeister]

Hi freetz,

ich hatte noch einen DHT11 rumliegen.... da die "DHT Temperature & Humidity Sensor library" den Typ auch unterstützt habe ich mal eine kleine Änderung erstellt. Mit

Code Auswählen Erweitern

#define DHT_TYPE11    // DHT11 or DHT12 in BSB_lan_config.h wird statt DHT22, DHT11 aufgerufen. Ohne dem define bleibt es beim bisherigen Verhalten.
https://github.com/loetmeister/bsb_lan/commit/7b62d48e61745a7100b084d76017075a1e873d35

Serial.print hatte ich auch auf DebugOutput.print geändert, dann kommt das auch da an wo es soll...

Code Auswählen Erweitern

GET /T HTTP/1.1
/T
DHT sensors: 1
DHT, OK
#dht_temp[0]: 22.00, hum[0]: 38.00

Passt das so? Würdest du das übernehmen wollen? 

EDIT:
Glaube ich habe zu viele Serial.print mit DebugOutput.print ersetzt... alle Serial.print(F("#")); ... sind Teil der Möglichkeit BSB_LAN über das Serielle Interface zu nutzen... richtig? 

Gruß,
Thomas

[freetz]

Ich hatte beim DHT damals überlegt, mich dann aber dagegen entschieden, denn er ist für "unsere" Bedürfnisse eigentlich kaum sinnvoll verwendbar. Er bildet nur Temperaturen über 0 Grad ab, und dann auch nur mit einer Genauigkeit von +/- 2 Grad Celsius. Wenn man so etwas anbietet und die Leute dann eher zum DHT11 greifen, weil der ein Euro billiger ist als der DHT22 und sich dann hier "beschweren", weil die Temperaturanzeige nicht stimmt und den Fehler in der Software vermuten, haben wir/ich das am Bein, das möchte ich gerne vermeiden.

Was die unterstützten Sensoren angeht, ist für mich weniger eher mehr, auch weil dann mehr Libraries gepflegt/aktualisiert werden müssen. Wenn es 1Wire Feuchtigkeitssensoren geben würde, hätte ich den DHT22 gar nicht unterstützt. So war der DHT22 schon eine Notlösung.

[Maista]

Moin,
@freetz
Es gibt 1wire Temp/Feuchte/Lux/Luftdruck/VOC ... "Module".

https://www.tm3d.de/shop/kategorien/bausaetze

https://www.tm3d.de/shop/kategorien/module

Durch die Emulation eines z.B. DS18B20 durch einen Attiny können verschiedene 1wire Fremde Sensoren benutzt werden.
Ich selbst habe diverse Module im Einsatz. Ein VOC-Sensor ist auch dabei.
In FHEM muss man dann die eingelesen Daten nur im entsprechenden 1wire Modul umrechnen.

Gruß Gerd

[loetmeister]

Hi,

ja stimmt... der Sensor ist nicht toll... aber die aktuelle Lib unterstützt ihn bereits, ich hatte es einfach nur nutzbar gemacht.

Mal ne frage zu den vorhandenen "Serial.print". Welche sind als loggin/debug Ausgabe gedacht, und welche Teil der Seriellen Kommunikationsfunktion?
(von dem Serial.print in setup() abgesehen)

Serielle Kommunikation

Code Auswählen Erweitern

Serial.print(F("#avg_")...
Serial.print(F("#dht_temp[...
Serial.print(F("#1w_temp[...

logging?
(welches man nach DebugOutput senden könnte?)

Code Auswählen Erweitern

              // Decode the rcv telegram and send it to the PC serial interface
              pvalstr=printTelegram(msg, line);
              Serial.print(F("#"));
              Serial.print(line);
              Serial.print(F(": "));
              Serial.println(pvalstr);
              Serial.flush();

EDIT: Eigentlich ist das logging ja schon in  printTelegram() enthalten.... d.h. es wäre auch Teil der Seriellen Kommunikationsfunktion....

Gruß,
Thomas

[freetz]

@Maista: Das ist ja interessant, allerdings auch deutlich teurer, als nur einen DS18B20 anzuschließen. Und ich müsste die rückgemeldeten Daten ja weiterhin auch auf BSB-LAN-Ebene auswerten, damit es auch standalone läuft wie jetzt. Da wäre die Frage, ob das dann auch ginge.

@loetmeister: Ja, verstehe ich schon, und ist an sich natürlich eine gute Idee, ich möchte nur die "Nebenfunktionen" von BSB-LAN, die für die Enduser aber am Ende nicht als solche zu erkennen sind, halt so weit wie möglich reduzieren.
Was die Ausgaben auf der seriellen Konsole angeht, sind das, was mit "#" beginnt, die Antworten auf Anfragen, die auf der seriellen Konsole reinkommen. BSB-LAN ist ja schon seit einiger Zeit auch (fast) komplett über die serielle Schnittstelle zu bedienen.

Noch eine generelle Anmerkung zu den Code-Optimierungen, die ja auch über GitHub in letzter Zeit eingegangen sind: Ich weiß den Einsatz wirklich sehr zu schätzen, den Code noch weiter zu optimieren, aber im Moment kostet es mich gerade nicht unerheblich Zeit, die Änderungen zu prüfen, die ja auch nicht in allen Fällen schon fehlerfrei waren, was dann wieder Arbeit auf allen Seiten nach sich zieht, zumal, wenn dann gleich an mehreren Stellen geschraubt wird. Der jetzige Code ist alles andere als "schön", auch deswegen, weil er organisch auf ein vielfaches seiner ursprünglichen Größe gewachsen ist (man schaue sich nur die erste Version auf einer der ersten Seiten an) und am Anfang wohl nie jemand gedacht hätte, dass es diesen Funktionsumfang für so eine Vielzahl an verschiedenen Heizungs- und Bussystemen einmal geben würde.
Mein Grundprinzip ist daher (auf BSB-LAN bezogen) "never change a running system", denn selbst da gibt es immer genug Fehler, die man noch ausmerzen muss. Neue Funktionen, die die Abwärtskompatibilität möglichst nicht einschränken, sind natürlich gerne gesehen, aber auch die sollten es sich nach Möglichkeit an dem "Kern" von BSB-LAN orientieren. Wo es mir wirklich helfen würde, wäre bei den noch offenen "Issues", z.B. UDP-Broadcast, mDNS, komplette Einstellungsmöglichkeit per Webinterface etc.

Danke trotz allem natürlich für den Einsatz und das Mitdenken!

[Maista]

@freetz
Tobias fing damit an den DS2423 und mit einem DHT22  ein DS2438 zu emulieren. Von diesem Dual-Counter gibt es nur noch Restbestände.
Er hat sich in die Protokolle ziemlich reingekniet.
Wenn du das integrieren willst und fragen hast, er hilft gerne
Achja, beim FHEM Modul zum DS2423 gibt es den Typ "DS2423emu". Der schreibt dann nichts in den internen Speicher.
Du könntest ja dadurch dann intern die Ausgabe umrechnen wenn der Typ ausgewählt würde.

Das nur als Idee falls dich lange Weile plagt

Gruß Gerd

[freetz]

Klingt nicht schlecht, wenn man damit mehrere Fliegen mit einer Klappe (und zu günstigen Preisen) schlagen kann, muss ich mir beizeiten mal anschauen...

[TV-age]

@freetz:
ich habe den Ser_Mon mal mitlaufen lassen. Siehe anbei. Einmal Version 0.44 und dann auch 0.43.
die config.h ist für beide gleich.
>>0.43

Code Auswählen Erweitern


18:57:44.112 -> ⸮昆⸮ address: 66
18:57:44.112 -> Destination address: 0
18:57:44.112 -> READY
18:57:44.112 -> Size of cmdtbl1: 30260
18:57:44.112 -> Size of cmdtbl2: 19788
18:57:44.112 -> free RAM:5287
18:57:44.691 -> 192.168.178.19
18:57:44.691 -> Waiting 3 seconds to give Ethernet shield time to get ready...
18:57:48.135 -> numSensors: 5
18:57:48.294 -> LAN->HEIZ QUR 6225 Konfiguration -  Gerätefamilie:
18:57:48.325 -> DC C2 00 0B 06 3D 05 00 02 52 88
18:57:48.325 -> HEIZ->LAN ANS 6225 Konfiguration -  Gerätefamilie: 163
18:57:48.362 -> DC 80 42 0E 07 05 3D 00 02 00 00 A3 B7 11
18:57:48.362 -> #6225: 163
18:57:48.562 -> LAN->HEIZ QUR 6226 Konfiguration -  Gerätevariante:
18:57:48.597 -> DC C2 00 0B 06 3D 05 00 03 42 A9
18:57:48.597 -> HEIZ->LAN ANS 6226 Konfiguration -  Gerätevariante: 5
18:57:48.597 -> DC 80 42 0E 07 05 3D 00 03 00 00 05 14 89
18:57:48.634 -> #6226: 5
18:57:48.634 -> Device family: 163
18:57:48.634 -> Device variant: 5
18:57:55.263 -> 10991 DC 8A 00 0B 06 3D 0D 05 19 4F 8C
18:57:55.331 -> 11061 DC 80 0A 0E 07 0D 3D 05 19 00 06 22 11 0D
18:57:56.928 -> GET /8700/T/8700 HTTP/1.1

18:57:56.965 -> /8700/T/8700
18:57:57.370 -> LAN->HEIZ QUR 8700 Diagnose Verbraucher -  Außentemperatur:
18:57:57.404 -> DC C2 00 0B 06 3D 05 05 21 B9 7C
18:57:57.404 -> HEIZ->LAN ANS 8700 Diagnose Verbraucher -  Außentemperatur: 20.2 °C
18:57:57.438 -> DC 80 42 0E 07 05 3D 05 21 00 05 0C 83 24
18:57:57.438 -> #8700: 20.2 °C
18:57:58.193 -> #1w_temp[0]: 21.31
18:57:58.261 -> #1w_temp[1]: 21.31
18:57:58.364 -> #1w_temp[2]: 21.25
18:57:58.464 -> #1w_temp[3]: 28.50
18:57:58.600 -> #1w_temp[4]: 30.25
18:57:58.872 -> LAN->HEIZ QUR 8700 Diagnose Verbraucher -  Außentemperatur:
18:57:58.906 -> DC C2 00 0B 06 3D 05 05 21 B9 7C
18:57:58.906 -> HEIZ->LAN ANS 8700 Diagnose Verbraucher -  Außentemperatur: 20.2 °C
18:57:58.940 -> DC 80 42 0E 07 05 3D 05 21 00 05 0C 83 24
18:57:58.940 -> #8700: 20.2 °C
18:58:00.396 -> 16024 DC 80 7F 15 02 2E 00 02 11 00 00 FF FF FF FF FF FF 00 00 F8 F1
18:58:05.380 -> 20963 DC 8A 00 0B 06 3D 0D 05 19 4F 8C
18:58:05.448 -> 21033 DC 80 0A 0E 07 0D 3D 05 19 00 06 22 11 0D
18:58:07.289 -> 22871 DC 80 7F 0E 02 31 00 02 12 00 00 00 F9 26
18:58:07.323 -> INF: TWW-Status: 0
18:58:15.449 -> 31023 DC 8A 00 0B 06 3D 0D 05 19 4F 8C
18:58:15.552 -> 31094 DC 80 0A 0E 07 0D 3D 05 19 00 06 22 11 0D
18:58:16.610 -> 32129 DC 80 7F 15 02 2D 00 02 11 00 00 FF FF FF FF FF FF 00 00 75 52
18:58:21.297 -> 36804 DC 80 7F 15 02 2F 00 02 11 00 00 FF FF FF FF FF FF 00 00 83 90
18:58:25.548 -> 41050 DC 8A 00 0B 06 3D 0D 05 19 4F 8C
18:58:25.650 -> 41120 DC 80 0A 0E 07 0D 3D 05 19 00 06 22 11 0D
18:58:35.659 -> 51123 DC 8A 00 0B 06 3D 0D 05 19 4F 8C
18:58:35.727 -> 51193 DC 80 0A 0E 07 0D 3D 05 19 00 06 22 11 0D


und dann 0.44

Code Auswählen Erweitern


18:51:01.653 -> READY
18:51:01.687 -> Size of cmdtbl1: 32334
18:51:01.687 -> Size of cmdtbl2: 20825
18:51:01.687 -> free RAM:4214
18:51:01.687 -> Reading EEPROM...
18:51:01.687 -> Starting SD..failed
18:51:04.645 -> 192.168.178.19
18:51:04.645 -> Waiting 3 seconds to give Ethernet shield time to get ready...
18:51:07.857 -> numSensors: 5
18:51:09.864 -> query failed
18:51:10.883 -> query failed
18:51:11.869 -> query failed
18:51:12.891 -> query failed
18:51:13.875 -> query failed
18:51:14.884 -> query failed
18:51:14.884 -> Device family: 0
18:51:14.884 -> Device variant: 0
18:51:14.884 -> GET /8700/T/8700 HTTP/1.118:51:14.918 -> /8700/T/8700
18:51:16.138 -> query failed
18:51:17.159 -> query failed
18:51:18.151 -> query failed
18:51:18.928 -> #1w_temp[0]: 21.25
18:51:18.996 -> #1w_temp[1]: 21.31
18:51:19.064 -> #1w_temp[2]: 21.25
18:51:19.200 -> #1w_temp[3]: 28.75
18:51:19.336 -> #1w_temp[4]: 30.62
18:51:20.399 -> query failed
18:51:21.417 -> query failed
18:51:22.402 -> query failed