Hallo liebes Forum,
ich versuche neuerdings einige Messdaten meiner künftigen Heizung (eine
Luft/Wasser-Wärmepumpe von Brötje) zu entlocken zur Aufzeichnung und
Auswertung.
Die sog. ISR-Plus-Regelung basiert lt. Systemhandbuch (darf man 2,8MB
PDF-Dateien anhängen?) auf dem LPB-Bus. Etwas Googelei verät, dass
dieser Bus von Siemens stammt - mehr auch leider nicht. Im Handbuch
steht zum Glück ein wenig mehr:
1
Technische Daten LPB
2
Physical Layer Spannungspegel und Zeichenübertragung gemäss nach ISO / OSI NF C 46 621
3
Data Link Layer Buszugriffsverfahren, Telegrammaufbau, Telegrammübermittlung nach ISO / OSI und Datensicherung gemäss NF C 46 622
4
Application Layer Siemens-spezifisch nach ISO / OSI
Übertragungs- durchschnittlich ca. 10 Telegramme pro Sekunde
16
kapazität
17
Buszugriffsverfahren CSMA / CA (Mehrfachzugriff mit Kollisionsverhinderung)
18
Adressbereich 1..240, aufteilbar in 15 Gruppen / Segmente zu 16 Geräten
19
Anzahl Teilnehmer bei verteilter Busspeisung: max. 16
Das ist ja schonmal eine Menge an Informationen. Also ist es ein Bus der
mit 4800 8U1 überträgt und die Pegel zwischen <7V und >9V liegen. NRZ
klingt nach RS232/UART. CSMA/CA muss ich erst berücksichtigen, wenn ich
auf den Bus schreiben will, richtig?
Leider komme ich auch bei den Normen nicht weiter. Physisch nach NF C 46
621 und Telegrammsicherung nach NF C 46 622. Weiß jemand was die
bedeuten?
Erstmal, da ich die Heizung noch nicht habe, würde es mir genügen,
physisch an den Bus zu kommen und die Daten mitzuprotokollieren. Wenn
ich dann später den Telegrammaufbau und die Daten dekodieren kann,
könnte ich so die 'verlorenen Daten' aufbauen.
Ich schreibe hier etwas ausführlicher, da es leider nicht viele
Informationen zu der ISR im Netz zu geben scheint.
Ich hoffe auf eure Anregungen und Informationen.
Vielen Dank schoneinmal,
Sascha
Hallo Helmut,
vielen Dank für den Hinweis-sieht auch ganz interessant aus.
Weil ich die Heizung noch nicht habe kann ich es leider noch nicht
ausprobieren. Damit das Projekt dann schnell weiter gehen kann, bin ich
für weitere Anmerkungen sehr dankbar.
Sascha
Hallo Sascha, weitere Informationen kann ich derzeit nicht bieten. Ich
bin jedoch dabei, ein Kästchen mit X-Port oder so zu stricken, um per IP
auf den LPB meiner neuen Brötje zu kommen. Was da softwaremäßig dazu
kommt, weiß ich noch nicht. Werde Neuigkeiten hier posten
Uli
Hallo Uli,
super, dass sich noch jemand gefunden hat, der in der gleichen Situation
steckt. Weil ich die Heizung noch nicht habe, sind die Infos oben leider
alles was ich habe.
Anbei auch das Systemhandbuch für den ISR - das bisher aussagekräftigste
wasa ich finden konnte. Speziell Kapitel 8 ist interessant ;)
Dann auf zu einem Ergebnis,
Sascha
Hallo Sascha, danke für das Systemhandbuch. Ich hab's selber da,
allerdings ist deine Version vermutlich aktueller als meine. Jedenfalls
kann kennt meine Heizung sehr viele Parameter, die in meinem Handbuch
noch nicht auftauchen.
Was stellst Du Dir als Schnittstelle vor, mit der Du weiterkomst? RS232,
Ethernet (vielleicht so, daß man mit Telnet draufkommt)? Ist für mich
interessant zu wissen, in welche Richtung es gehen könnte.
Nochmal zum terminlichen: Ich denke vor September kann ich mich da nicht
ransetzen aber da ich selbst eine Lösung benötige, wird es auf jeden
Fall werden.
Bis später, Uli
Hallo,
da ich auch eine Brötje-Heizung besitze, bin ich auch an dem Aufbau
einer Kommunikation interessiert.
Ich habe ein interessantes Dokumant gefunden, der beschriebene
Telegrammaufbau könnte passen:
https://prof.hti.bfh.ch/uploads/media/BatiBus_v1.4.pdf
Grüße
dj999
Danke dj für das Dokument - besonders der Frame-Aufbau und die
Veranschaulichung der Signale finde ich interessant.
Als Schnittstelle werde ich erstmal einen Pegelwandler und einen AVR
verwenden.
Grüße
Sascha
Ich denke, dass der Adapter von Helmut schon ganz gut aussieht. Den
Sendeweg möchte ich allerdings ersteinmal weglassen, damit ich nicht
irgendwelche Daten an die Heizung schicke (zumal ich diese erst seit
gestern im Haus habe g)
Zumindest hätten wir dann einen Sniffer, der die Daten lesbar von der
Leitung holt.
Danach sollten Daten gesammelt werden um diese auswerten zu können. Ich
hoffe, dass die Heizung von sich aus erzählt was so passiert und wir
nicht alles abfragen müssen...
Hallo zusammen,
oute mich hier auch als Brötje-Besitzer und Informationsgieriger des LPB
:)
Habe mir die Schaltung von Helmut mal angesehen (nicht daß ich was von
analoger Elektronik verstehen würde...) und bin über die 2-fache
Negierung "gestolpert"...
Laut LPB Spec sind Buspannungen > 9V logisch "0" und < 7V logisch "1".
Nach dem ersten NAND-Gatter würde doch, wenn auf dem Bus logisch "0"
anliegt (also Spannung > 9V), auch eine logische "0" rauskommen, oder?
Falls das so ist, dann würde das 2. Gatter doch daraus eine "1" machen?
Naja, ist mir nur aufgefallen :)
Ist denn schon jemand weiter mit der Schaltung und hat vielleicht sogar
schon mitgesnifft?
Wäre schön, wenn wir das kleine Projekt hier etwas vorantreiben
könnten...
Grüße aus der Pfalz,
//rudi
So weit war ich bei meinen Überlegungen noch gar nicht ;)
Deine Schaltung funktioniert ja auf dem eBus (und wahrscheinlich vielen
anderen) einwandfrei (setze ich jetzt einfach mal als gegeben voraus).
Laut eBus Spec liegt eine logische "1" an, bei Spannungen > 15V, und
eine "0" bei Spannungen ~ 9V. Die beiden NAND-Gatter machen also aus
einer logischen eBus "1" zuerst eine "0" und dann wieder eine "1". Ist
also "logisch richtig" :)
Bei LPB liefert die hohe Spannung aber eine logische "0", die liegt dann
schon nach dem ersten NAND-Gatter an...
Versuch einer tab. Darstellung der logischen Zustände bei Anlegen der
Busspannung:
Bus nach NAND 1 nach NAND 2
eBus 1 0 1
LPB 0 0 1
Bei LPB kommt also "hinten" nicht das an, was "vorne" reingeht ;)
Zum MAX232: nach meinem Verständnis invertiert er nicht die logischen
Zustände, sondern nimmt nur eine Anpassung der TTL-Pegel and die RS-232
Pegel vor.
Uff... noch eine Tabelle:
log. "0" log. "1"
TTL 0V 5V
232 +3...+25V -3...-25V
Wenn also am Eingang des MAX eine logische "1" (TTL 5V) anliegt, muss er
eine negative Spannung erzeugen, um die "1" auch richtig an die serielle
weiterzugeben...
Soweit also mein Verständnis, wobei die Welt in meinem Kopf aber nicht
immer realitätsnah ist ;)
//rudi
Hallo nochmal,
habe mittlerweile noch etwas rausgefunden: bei einer logischen "1" liegt
auf meinem Bus 0 Volt an. Die LPB Spec stimmen zwar ( < 7 Volt) aber mit
0 hätte ich nicht gerechnet...
Das wirkt sich, höchstwahrscheinlich, auch auf die Versorgungsspannung
aus... vielleicht eine externe 5V Versorgung für die Schaltung, oder
einen entsprechend großen Kondensator hinter den 7805, wobei ich, wie
schon erwähnt, mich da nicht sonderlich auskenne...
Jemand hier, der das kommentieren bzw. ausrechnen könnte?
//rudi
Du solltest die Schaltung einfach mal aufbauen.
Sie läuft auf dem E-Bus und auf dem Buderus EMS-Bus, ist getestet.
Das Verständniss-Problem ist bei vielen Leuten, dass dieser Adapter nur
den Bus auf RS232 umsetzt, lesen und senden, nix anderes.
Die Daten werden aber nicht decodiert oder geordnet.
Wer die Applikationen von Buderus, Wolf oder was weiß ich kennt, weiß
was da auf dem Bus los ist.
Mit einer Wolf-Heizung und IPSymcon gibt es schon eine Art Ordnung der
Busdaten, weil ein begnadeter User ein Modul dafür gemacht hat.
Auch die Checksummen-Geschichte ist von ihm erfasst worden.
Gruß Helmut
Hallo an die Freaks hier,
ich bin seit einem viertel Jahr im Besitz einer EcoTherm WGB 15E ohne
zusätzliche Austattung (1 Heizkreis).
Mich interessiert das Projekt, da ich dieses Gerät gern irgendwie an
meine vorhandenen KNX-Komponenten "schrauben" möchte. Es geht aber damit
los, daß es scheinbar keinen Buanschluß gibt. Zumindest eine Klemme
existiert nicht, die für den LPB-Bus da sein könnte. Ich weiß aber, daß
es ein Busmodul BBM gibt. Benötige ich das auf jeden Fall?
Danke und Gruß Holger
PS: Ich weiß, fast am Thema vorbei aber ohne Busanschluß keine
Testschaltung...
Du brauchst dazu ein Busmodul CIB (Typ OCI 420) welches auf deine BMU
gesteckt wird. Ohne dem kein LPB.
Muss mal suchen, habe mindestens noch ein solches über.
Im Anhang eine Info zum Bus aus der Doku
Hallo Zusammen,
ich besitze seit 3 Tagen nun auch eine Brötje EcoTherm mit einem
Busmodul CIB. Bin sehr interessiert an den Ergebnissen. Hat jemand schon
mit einem oder anderem Modul die Daten lesen können?
Gruß
Simon
Hallo,
ich hatte bereits im September schon einmal hier ein paar Infos
hinterlassen und die Zeit über hin und wieder mal den Verlauf des Themas
verfolgt.
Es ist nicht unbedingt erforderlich ein LPB-Modul nachzurüsten, da die
Thermen, wenn sie von SIEMENS kommen, meist bereits mit BSB ausgestattet
sind. BSB steht hier für "BoilerSystemBus" und scheint eine
"vereinfachte" Ausgabe des LPB's zu sein.
Mittlerweile hat auch SIEMENS reagiert und nun das hier in Mitteleuropa
kaum zu erhaltene OZS164.xx durch das OZW672.xx ersetzt. Das OZS wird
abverkauft...
Genial ist, dass, wenn man nur eine Therme überwachen will, das Gerät
auch nutzen kann - ohne LPB - eben auf dem besagten BSB!
Nähere Informationen und auch die dazu unterstützen Geräte findet Ihr
hier:
https://www.swe.siemens.com/greece/internet/en/pss/IC/BT/Documents/OZW67(en).pdf
oder im beigefügten PDF.
Alles hat nur einen Haken:
SIEMENS verlangt minimum 380€ für das Teil....
Gruß
Leuschman
Guten Abend!
ich bin seit heute zu einer Brötje Brennwertheizung gekommen. (brötje
ecotherm plus wgb 20e)
Ich bin sehr interessiert, den Bus an einen Controller o.a.
weiterzuleiten.
@kuschelganxta: Bist du schon weiter gekommen?
Ist die 3 Drahtleitung zum RGT dafür geeignet, oder benötigt man
OZW672?
Ich hoffe, wenn das Protokoll nicht allzu kompliziert ist, komme ich
ohne aus.
Mir geht es in erster Linie darum, die Betriebsdaten zu loggen.
Hallo zusammen,
hier scheint es ja einige Interessierte zu geben, daher mal der aktuelle
Stand:
- Der BSB ist interessanter als der LPB, weil lt. Systemhandbuch der
LPB quasi-extern und der BSB 'Heizungs-Intern' genutzt wird. Das
RGT/QAA7x verwendet auch den BSB.
- BSB und LPB sind ja lt. Spezifikation gleich also wird sich nur der
Appl. Layer unterscheiden.
Und hier der "Fortschritt":
Ich habe mal meinen kleinen LA ausgepackt und bin an den RGT gegangen
(ohne Bus-Verbindung). Per Spannungsteiler 100k/50k und CL+-Spannung=15V
versucht das RGT nach einigen Sekunden den Bus abzufragen...
Leider lässt sich mit dem UART-Protokoll-Analyser keine saubere
Übertragung finden.
Es ergeben sich neue Fragen:
- Warum werden keine Zeichen übertragen sondern anscheinend nur die
Bus-Leitung getoggelt? Löst das ein Antworten der Zentrale aus?
- Sehen die Daten auf dem Bus anders aus?
Ich werde mal mutig sein und die Heizung anzapfen...mal sehen, ob hier
sauber mit 4800-8O1 übertragen wird. Aber erst später ;-)
Grüße
Sascha
Auch ich hätte Interesse an der Steuerung über den LPB oder BPB BUS.
In Internet sind kaum Infos zu bekommen. Scheint wirklich gut behütet zu
sein :-(
Ich schau hier gelegentlich mal vorbei, eventuell kann ich ja etwas
unterstützen.
maltec
So, Fortschritt:
- Beim Anschluss des RGT/QAA75.611 bin ich auf Suche nach dem BSB
gegangen, da ich keine weitere Leitung nach Außen legen wollte.
- Die Klemmen CL+ und CL- sind am Erweiterungsmodul/EM-BUS (glaube
Bezeichnung X30 oder X50) verfügbar und werden vom AVS37 genutzt.
- Am AVS37 gibt es vorn eine Service-Buchse mit Stiftleisten. Hier kann
gut ein AVR ran. BSB sind die mittleren Pins (messen welcher CL+ und
welcher CL- ist. Spannung war bei mir 11.7V und leichte Einbrüche bei
Übertragung)
- Ein einfacher Spannungsteiler (30k nach CL+, 10k nach CL-) ermöglicht
das Mitschneiden mit einem AVR (4800Baud, 8U1).
Ich werde die Tage mal den Aufbau beschreiben und Daten liefern.
Aufbau wiefolgt:
- BSB CL+ ist Pin 2 von oben am Bediengerät (Service-Buchse). CL- ist
Pin 3 (Foto 1).
- Test mit RGT/QAA78.610 erfolgreich (Foto 2)
- BSB-zu-USB: Spannungsteiler mit 2.2k und 1.5k Widerstand an USB-UART
anschließen. Z.b. mit HTERM mit 4800baud, 8 data, 1 stop, odd Parity
verbinden. Die Daten kommen im Sekundentakt oder öfter.
Hier einige Daten:
# Heizbetrieb, Anzeige Standby (auch bei TWW-Betrieb)
REQ: 23 75 FF F4 F9 C2 FA F8 4F 5B 73
RET: 23 7F F5 F2 F8 FA C2 F8 4F FF 76 11 1E
# Aus, Solltemp erreicht, Anzeige Standby
REQ: 23 75 FF F4 F9 C2 FA F8 4F 5B 73
RET: 23 7F F5 F2 F8 FA C2 F8 4F FF E6 92 A7
# Aus, Solltemp erreicht, "Gesperrt EVU"
REQ: 23 75 FF F4 F9 C2 FA F8 4F 5B 73
23 7F F5 F2 F8 FA C2 F8 4F FF F5 B0 F5
Byte
1 Fest 23?
2 Ziel/Quelle? Manchmal 7B, evtl. Raumfühler (75 Bedienteil, 7F
Regler, 7B Raumfühler)???
3 NOT, Dezimal, Datenlänge Gesamtpaket in Bytes
4
5
6
7
8
9
10
11
12
13
# Raumfühler?
23 79 FF F1 FD C2 D2 FD EA FA C5 FF 07 BE
23 79 80 EB FD FA FF FF 93 FF 8F F4 E5 FE EE C4 F7 FF C1 67 # 20.8
23 7B FF ED FD FA FF FD D6 FA C3 06 FF 9B FE FB 0F 37
# TWW aktiv, HKP aus, Verdichter an, Komp an, Heizbetrieb, Mischer TWW
REQ: 23 75 FF F4 F9 C2 FA F8 4F 5B 73
23 7F F5 F2 F8 FA C2 F8 4F FF 76 11 1E
# Raumfühler fragt TTW-Temperatur 1 (8830)
23 79 FF F4 F9 C2 CE FA D0 47 95
23 7F F9 F1 F8 CE C2 FA D0 FF F8 A0 95 11 # 29,5 °C
23 7F F9 F1 F8 CE C2 FA D0 FF F8 2D D5 34 # 31,3 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F7 CD DF 5A # 32,8 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F7 67 CB FA # 34,4 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F7 0B 66 D0 # 35,8 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F6 A1 41 41 # 37,5 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F6 48 2D 46 # 38,9 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F5 FF AF 29 # 40,0 °C
23 7F F5 F1 F8 CE C2 FA D0 FF F5 E9 DD DE # 40,3 °C
# vom Regler
23 75 FF F4 F9 C2 CE F8 B4 1C 62
23 7F F5 F1 F8 CE C2 F8 B4 FF FE BF EC B7 # 39,8 °C
# ISR fragt außentemperatur (8700)
23 75 FF F4 F9 C2 FA FA DE AE 89
23 7F F5 F1 F8 FA C2 FA DE FF FE 02 77 70 # 8,0 °C
23 7F F5 F1 F8 FA C2 FA DE FF FD EE 1E 81 # 8,3 °C
23 7F F5 F1 F8 FA C2 FA DE FF FD E2 DF 0D # 8,5 °C
23 75 FF F4 F9 C2 FA FA DE AE 89
23 7F F5 F1 F8 FA C2 FA DE FF FD ED 2E E2 # 8,3 °C
23 7F F5 F1 F8 FA C2 FA DE FF FD E8 7E 47 # 8,4 °C
# Raumtemp 1
23 7F F5 F1 F8 D2 C2 FA 6C FF FA BF 2C 20 # 20.8 °C
# TWW ausschalten
23 75 FF F2 FC C2 CE FA 8E FE FF CD 5B
23 7F F5 F4 FB CE C2 FA 8E F1 FB
# 8400, Verdichter aus
23 75 FF F4 F9 C2 FA F6 4A 28 D9
23 7F F5 F2 F8 FA C2 F6 4A FF FF 58 15
Die Daten scheinen invertiert zu sein - die Werte sind sehr "hoch".
Evtl. ist ein invertierender Transistor noch sinnvoll - oder halt in
Software.
Das Ganze läuft über Frage/Antwort. Ich gehe davon aus, dass nur der RGT
periodisch seinen Ist-Wert auf den Bus legt.
Der grobe Paketaufbau scheint einfach. Start ist immer 23, gefolgt vom
Quell-Gerät (7F Regler, 75 Bediengerät, 79 RGT), dann ein Byte was wie
ein "Anzahl folgende Daten" aussieht und ein paar festen Bytes. Dann
Daten dann eine Prüfsumme.
Hat jemand die Muse sich damit einmal auseinander zu setzen?
Grüße
Sascha
Hallo zusammen,
ich habe seit kurzem einen Brötje Öl-Brennwert Heizung im Keller stehen
und würde gerne einige Daten aus der Heizung an eine übergeordnete
Gebäude Steuerung übergeben.
Nur weis ich jetzt nicht genau wie ich an die Daten in der Heizung heran
komme. Ich habe mir das hier duchgelesen und hab das vorgehen nicht ganz
verstanden, da steht irgenwas von EBus adapter und dan was von einem
MAX.
Könntet ihr mal Posten wie die Kommunikation elektrisch aufgebaut wird?
Gruß
Sebastian
Hallo Sascha,
das sieht doch schon ganz gut aus. Leider habe ich kein
externes Bediengerät so wie du. Ich würde nun meinen raspberry dran
hängen über den usb uart mal versuchen die die daten mitzuschneiden.
Hast du über Hyperterminal mal ein paar Kommandos an die Therme
geschickt um zu sehen was sie macht?
Gruß
Erik
erik schrieb:> das sieht doch schon ganz gut aus.
Danke, inzwischen habe ich auch eine Mapping-Tabelle mit
Daten/Temperaturen zusammen und kann lustige RRD-Grafiken erstellen -
openHAB auf dem Raspberry sei dank ;-)
> Leider habe ich kein externes Bediengerät so wie du.
Ist auch nicht wirklich notwendig - ich sehe es so, dass die Telegramme
problemlos emuliert werden können.
> Ich würde nun meinen raspberry dran> hängen über den usb uart mal versuchen die die daten mitzuschneiden.
Mitschneiden ist einfach. Steht ja schon oben in meinem Post wie das
geht ;)
> Hast du über Hyperterminal mal ein paar Kommandos an die Therme> geschickt um zu sehen was sie macht?
Ich sende noch nicht, da ich nicht wüsste was ;-) Später will ich in
Abhängigkeit der zu erwartenden Außentemperaturen die TWW-Bereitung und
Aufheizphasen in günstige Zeiten legen.
Meine aktuelle Meinung zu Absenkung mit Wärmepumpe/Neubau:
Bringt nichts. Bis alles wieder auf molliger Temperatur ist vergeht
zuviel Zeit. Außerdem gerät die Luft/Wasser-WP dann sehr oft in die
Abtauung -> Ineffizient.
Ich habe die Heizung konstant auf 21,5° mit Hysterese von 0,5° nach
unten. In 'günstigen Zeiten' (Nachtstrom, hohe zu erwartende AußenT)
erwärme ich auf 22,25° was dann recht angenehm ist und lange vorhält -
und Geld spart.
Sehr schade finde ich die codierung der Daten, die bestimmt einige Zeit
in Anspruch nehmen wird.
Grüße
Sascha
Hallo Sascha,
okay eine wärmepumpe habe ich leider nicht
ich verballere das gute erdgas....
und da ich die 200m² altbau nun mit 800m³ x 10 = 8000 kwh erdgas in den
letzte 3 monaten befeuert habe muss ich mir nun dringen was einfallen
lassen. bei erdgas bringt die nachtabsenkung schon einiges deshalb würde
ich das ding ganz gerne über ein webinterface einstellbar haben, denn
wenn man mal etwas länger macht muss man dann nicht in den keller um die
therme anzuwerfen ;-) am besten wäre für mich die Therme über einen
google kalender zu steuern, avm scheint ja da was machen zu wollen mit
der fritzbox....
mal sehen was wird auf jedne fall schon mal danke für die infos,
und wenn du irgendwie an die beschreibung des protokoll dran kommst dann
lass es mich wissen ;)
Gruß
Erik
So, jetzt nochmal ausführlich:
0xDC Start-Of-Frame ist korrekt. Die Seite erläutert Layer1 schon sehr
gut - dem gibt es nichts mehr hinzuzufügen
Meine Heizanlage scheint in einem anderen Segment zu stehen - die
SRC-Felder sind um +80 erhöht.
Hier ein paar interessante Telegramme:
Wird alle 10 Sekunden vom Bediengerät abgefragt (Anzeige "Standby"):
Status Wärmepumpe
DC 80 0A 0D 7 5 3D 7 B0 0
19 6D 58 WP aus
7D 41 7A Abtauen
02 CE 02 Störung
18 7D 79 Frostschutz
89 EE E1 Heizbetrieb
0A 4F 0A EVU-Sperre
25 9A 87 Begrenzungszeit aktiv
Sendet der Raumregler periodisch (ca. 60 Sekunden)
DC 86 0 0E 2 3D 2D 2 15 5
Byte 13 & 14 sind nicht die Temperatur. Diese versteckt sich in Bytes 10
&11. Excel-Sprech: =HEXINDEZ(BYTE10&BYTE11)/64 :-)
5 8C 22,1875
5 8A 22,15625
3 F0 15,75
etc
Warum sich auch über die letzten Bytes eine relation zur Ist-Temperatur
herleiten lässt kann ich nur vermuten: Evtl. wird hier ein Wärmedefizit
mitgeteilt?
Sollte ich am Wochenende endlich mal dazu kommen, werde ich mal etwas an
den Bus senden.
Sascha
Hallo zusammen,
da ich meine Brötje Gasheizung auch anzapfen möchte, habe ich mir die
Daten mal angesehen.
Bei Saschas letztem Posting habe ich leider nicht ganz verstanden wie
die gezeigten Fragment genau Telegramme (Anfrage und Antwort) bilden
aber ich versuche derzeit aus den ersten Daten schlau zu werden. Die
Temperaturumrechnung mit /64 funktioniert dort auch.
Ich versuche irgendwie die Parameternummern aus dem Handbuch in den
Telegrammen wiederzufinden. Leider habe ich kein RGT. Sascha, könntest
Du bitte die folgenden Parameter auslesen und Anfrage und Antwort
posten?
8830 Trinkwassertemperatur 1
8831 Trinkwassersollwert
8801 Raumsollwert P
8700 Außentemperatur 0
8703 Außentemperatur gedämpft 0
8704 Außentemperatur gemischt 0
1610 Nennsollwert
1612 Reduziertsollwert
710 Komfortsollwert 20
712 Reduziertsollwert 16
714 Frostschutzsollwert 10
501 1. Phase Ein 06:00 1. Phase Ein
502 1. Phase Aus 22:00 1. Phase Aus
503 2. Phase Ein 24:00 2. Phase Ein
504 2. Phase Aus 24:00 2. Phase Aus
Danke und Gruß,
Jens
Na klar, mach ich heute mal.
Die Parameter<->Adress-Zuornung habe ich auch noch nicht geschafft.
In meinem obigen Posting ist nur die Antwort des Reglers (Status WP) und
das Telegram des RGT zu finden. Das letztere sendet sich automatisch ;)
Im Systemhandbuch habe ich auf den Seiten 46ff in den Tabellen
Min/Max-Werte gefunden. Evtl. orientiert sich die Berechnung an den
Min/Max-Werten.
Bisher würde ich auf folgenden Telegram-Aufbau setzen:
1
Byte Kennung Bezeichnung
2
1 SOF Start-of-Frame
3
2 SRC SENDER Phy Adresse
4
3 RCV Receiver Phy Adresse
5
4 LEN Telegramlänge
6
5 TYP1
7
6 UKN
8
7 UKN
9
8 A1
10
9 A2
11
10..LEN DATA
Hier die SRCs der unterschiedlichen Geräte. Ich habe 2
Erweiterungsmodule, kann aber noch nicht zuordnen, welches Modul welche
Adresse hat.
Hallo zusammen,
@Jens:
Den 8831 habe ich nicht?!? Anbei die Traces der verschiedenen Parameter.
Der Dateiname enthält nach dem Punkt den angezeigten Parameter. Vorn
angefügt ist ein UNIX-Timestamp.
Die Aktion habe ich am RGT und auch am Bediengerät gemacht. Der einzige
Unterschied sind SRC und RCV.
Ich würde gern möglichst viel Informationen erhalten ohne den Bus mit
dauernden Status-Abfragen "zuzumüllen".
Interessant finde ich noch die Außen-Temperatur. Hier fällt mir dieses,
regelmäßig von selbst gesendete Telegramm auf, das scheinbar an Alle(7F)
gesendet werden soll:
DC 80 7F 17 02 05 00 02 19 00 93 00 00 FF FF FF FF FF FF 00 0F 11 E8
Also dann, ran an die Daten ;)
Sascha
Hallo zusammen,
ich habe seit kurzem einen Brötje Öl-Brennwert Heizung im Keller stehen
und würde gerne einige Daten aus der Heizung an eine übergeordnete
Gebäude Steuerung übergeben.
Was für eine Schnittstelle nutzt ihr und die schließe ich das an meinen
PC an? RS232 und MAX? habt ihr ein Schaubild für mich?
Gruß
Sebastian
@Sebastian:
wegen fehlender Zeit und schnellem Internet (Telekom kriegt echt gar
nichts hin!) hier nur ein paar Links zum kurzen Einlesen:
[1] http://de.wikipedia.org/wiki/Spannungsteiler
[2] http://de.wikipedia.org/wiki/Transistorgrundschaltungen
[3]
http://forum.electronicwerkstatt.de/phpBB/Projekte_im_Selbstbau/signal_invertieren_mittels_transistor-t26077f34_bs0.html
Die grundsätzliche Schaltung habe ich oben beschrieben (27.11.2012 10:29
). Ergänzt werden muss diese extrem einfache Schaltung erstmal (zum
Empfangen) nur um einen invertierenden Transistor (siehe Link 2)
@All:
Parameter 8700 (Außentemperatur):
Anfrage vom Bediengerät: DC 8A 00 0B 06 3D 05 05 6F F8 7C
Antwort 2,2°C: DC 80 0A 0E 07 05 3D 05 6F 00 FD 8E F5 4A
Antwort 2,3°C: DC 80 0A 0E 07 05 3D 05 6F 00 FD 93 36 D6
Letzten 3 Bytes nehmen, von HEX in Dezimal umwandeln und das Ergebnis
durch 4096000 teilen. Negative Temperaturen habe ich noch nicht
raus...und das im Winter :(
Sascha
Hallo Sascha,
danke erstmal für deine Antwort, mir bleiben da nur noch ein paar Fragen
offen:
Wie genau wird denn der Spannungsteiler angeschlosen?
2,2k Widerstand an CL+ ?
1,5k Widerstand an Cl- ?
Die beiden freien Beine zusammen an den UART?
Welchen UART hast du genommen?
Welche Pins am UART hast du wie genutzt?
Wie wird der invertirend Transistotr (Emiterschaltung siehe Anhang?)
dazugeschaltet?
Was für einen Transistor hast du genutzt?
Gruß
Sebastian
Hallo Sascha,
ich habe das jetzt mal aufgemalt wie ich deine Ausführungen verstanden
habe. Nur kann ich so ja nur empfangen, wie sieht das mit dem Senden
aus?
Gruß
Sebastian
Hallo Sebastian,
ja, das hast du vollkommen richtig verstanden.
Danke für die Zeichnung - das erleichtert es anderen schneller
einzusteigen :)
Das Senden habe ich bisher nur ein paar Mal hinbekommen - basierend auf
dem eBUS-Adapter empfohlen von Helmut ganz weit oben.
Aufbau ist CL+ -- 100 Ohm Widerstand -|- CL-/GND. Zwischen CL-/GND und
Widerstand einen NPN-Transistor (ich habe 2N2222), der dann die Leitung
auf 0 zieht.
Das schwierige beim Senden ist CSMA/_CA_. Hier gilt es anderen
Telegrammen nicht "in die Suppe zu spucken". Bei richtigem Timing landet
die Botschaft dann auch auf dem Bus. Ebenso ist die Parity zu beachten -
das macht aber der USB-UART.
Grüße
Sascha
Zum Thema Aussentemperatur, diese wird per Bus allen anderen Teilnehmern
zur Verfügung gestellt, sowohl den Raumgeräten via BSB als auch den
Regelgeräten via LPB.
Ich habe derzeit:
Gasbrenner
und Display im Gerät am BSB
und ClipInModul am BSB für den LPB
daran:
-SolarSystemRegler
und 2 Erweiterungsmodule am BSB
und 4 Raumgeräte (3x HKs + 1x ext. Servicegerät)
und Aussenfühler
-2-ZonenRegler
und 2 Raumgeräte
geplant noch:
-2-ZonenRegler
und 2 Raumgeräte
und 2 RaumThermostate
Ich finde das echt spannend weil ich daneben eine S7 mit WagoKlemmen
habe
die nur darauf wartet an die Sensorwerte der Heizung zu kommen.
Mal sehen ob ich Musse finde den Adapter zu bauen.
Hallo Jungs!
Frohe Weihnachten!
Hab noch nicht alles gelesen, bin aber hoch interessiert.
Werde diesen Thread ganz besonders verfolgen, denn ich muss auch noch
für eine Brötje (gleicher Regler) eine Fernsteuerung bauen. Das kostet
von Brötje mit Einbau fast 2000 Euro. Hab schon gesehen, dass man
einfach da ran kommt, aber ich will versuchen das über IP zu schalten.
Wenn also jemand da was macht oder gemacht hat, immer her damit! Man
muss ja das Rad nicht immer neu erfinden.:-)
Außerdem werde ich da nächstes Jahr wahrscheinlich auch noch nicht zu
kommen
Danke schon mal an dieser Stelle!
Liebe Grüße
Frank
Danke für die Informationen, Numsi.
Du scheinst ja dein Gebäude Heiz-Technisch voll auf LPB aufzubauen.
Ich vermute auch die Zeit und Außentemperatur in den Telegrammen, die an
7F geschickt werden. Aber die Bytes zu finden ist schwierig ;)
@Frank:
Natürlich wäre eine Ethernet<->BSB-Schnittstelle toll - am Besten mit
kleiner Visu und REST-Schnittstelle für andere Systeme. Aber da ist noch
ein ganzer Weg dazwischen :-(
Weihnachtliche Grüße
Sascha
Sascha K. schrieb:> @Frank:> Natürlich wäre eine Ethernet<->BSB-Schnittstelle toll - am Besten mit> kleiner Visu und REST-Schnittstelle für andere Systeme. Aber da ist noch> ein ganzer Weg dazwischen :-(
:-):-):-):-) Hast ja noch das ganze nächste Jahr Zeit, erst 2014 brauche
ich das.:-):-):-):-):-)
Außentemperatur steckt im regelmäßig von selbst übertragenden Telegramm
"DC 80 7F 17 02 05 00 02 19":
DC 80 7F 17 02 05 00 02 19 01 FF 00 00 FF FF FF FF FF FF 00 0F 0F FB
Außen: 7.98437
Berechnung analog Innentemperatur:
Bytes 10+11 von HEX in Dezimal umwandeln ("01FF"=>511) und durch 64
teilen (511/64=>7,984375°C). Ebenso ist hier noch offen, wie die
negativen Zahlen dargestellt werden.
Späte Grüße
Sascha
Update: Puffer-, TWW- und HK-Vorlauf sind entschlüsselt :)
Problem: Das wird nur gut gehen, wenn die Fühler an Erweiterungsmodulen
angeschlossen sind, da die Telegramme von diesen Modulen kommen.
Vorlauf:
DC 84 00 12 02 05 00 02 29 .............
Bytes 10+11, Berechnung wie die anderen Temperaturen
TWW & Puffer:
DC 83 00 12 02 05 00 02 29 .............
Bytes 10+11: TWW
Bytes 12+13: Puffer
Das ganze gibt dann dank OpenHab auf meinem Raspberry ein schönes Ding
für wenig Geld... schaut euch einfach die Grafik an :-)
Gute Nacht,
Sascha
So, die Daten kommen von der Grafik ganz gut hin :-)
Und das Beste: Alles, ohne eine Abfrage aktiv zu schicken.
Zur Verdeutlicherung mal mein Heizungsaufbau:
- Luft/Wasser-Außengerät mit Heizstab,Verdichter,Kompressor und
RVS41-Grundgerät
- Innen stehen Puffer, TWW-Speicher, Kondensatorpumpe (Förderpumpe WP),
Mischer, Regelgerät AVS37 mitsamt 2 Erweiterungsmodulen hintenan.
- Über ein paar Meter Kabel geht dann der BSB an einen Arduino, der auf
dem Bus mit dem oben beschriebenen Spannungsteiler auf dem BSB lauscht
und die Daten per USB/Seriell an einen Rasperry weitergibt. Auf dem
Raspberry läuft openHAB.
- Das BSB-Kabel geht noch weiter und endet an einem QAA75.610. Oben habe
ich mich vertippt fällt mir gerade auf :-/
Was gibt es jetzt noch zu forschen:
- Negative Temperaturen ausrechnen
- Vernünftig auf den Bus zu senden und CSMA/CA beachten
- Soll-Temperaturen setzen (Raum, TWW), evtl. Zeitplan ändern
Und nun schöne Zeit mit euren Familien :)
Sascha
@Sascha: Deinen Kopf möchte ich haben.
Toll gemacht.
Bis ich so was umsetzen kann, das dauert wohl noch.
Darf ich mich, wenn ich da mit anfange (ungefähr in 2014) mal an dich
wenden, wenn ich hänge?
Hallo,
ich bin auch schon lange auf der Suche nach einer Lösung. Wie wandelt
Ihr die Daten in lesbare Informationen um. Habt Ihr ein Skript (PHP)
oder was ähnliches ?
Gruß Uwe
Hallo,
bei mir ist der physische Aufbau wie oben beschrieben.
Layer 0 wird über den Spannungsteiler erledigt
Layer 1 ist das Parity-Bit
Danach geht es vom Arduino zum Raspberry, der die fertigen Bytes
über die serielle Schnittstelle annimmt. Hier wird über ein kleines
UNIX-Skript aus den Telegrammen der Inhalt interpretiert - hauptsächlich
mit grep, cut & co.
Wenn ihr wollt, kann ich mein Skript mal online stellen.
Schöner wäre natürlich eine vernünftige Klasse direkt auf dem Arduino,
die auch gleich das Checksumming erledigt und ungültige Telegramme
verwirft.
Übrigens:
Im alle 285 Sekunden selbst-versendeten Telegramm
DC 86 7F 14 2 5 0 0 6C 0 70 0C 7 5 12 29 6 0 6F CD
steckt in
Byte 15 Stunde in HEX
Byte 16 Minute in HEX
Byte 17 ist vermutlich Sekunde in HEX
Byte 13 und 14 werden vermutlich weitere Status-Informationen sein.
Byte 13 hat in meinem Log bisher die Werte 0x07,0x08,0x09,0x0A
angenommen
Byte 14 hat in meinem Log bisher die Werte 0x01,0x05,0x06,0x09
angenommen
...oder halt codiert der Wochentag ;)
Grüße
Sascha
Hi Sascha,
ich habe meine HomeAutomation in IPS-Symcon erstellt. Die Programmierung
dort ist in PHP. Dein Skript zur Auswertung wäre mal interessant.
Gruß Uwe
Sascha K. schrieb:> Wenn ihr wollt, kann ich mein Skript mal online stellen.
Ja bitte, auch einen Schaltplan wie da wo der Spannungsteiler rein
kommt.
Hab leider bisher nur sehr wenig Ahnung und wäre sehr froh über jede
Zeile.
Frank O. schrieb:> Ja bitte, auch einen Schaltplan wie da wo der Spannungsteiler rein> kommt.
Wow - sehe ich gerade erst - im Blog von dest-unreach.be ist sogar eine
Optokoppler-getrennte Ausführung inkl. Sendestufe:
http://blog.dest-unreach.be/2012/12/14/reverse-engineering-the-elco-heating-protocol> Hab leider bisher nur sehr wenig Ahnung und wäre sehr froh über jede> Zeile.
Ich geb mir Mühe ;-)
Grüße
Sascha
Nach meinen Kenntnissen kommt der Webserver von Siemens (Die Regelung
ist eine Siemens!) nächstes Jahr in Deutschland auf den Markt. Mit
diesem wird es wohl möglich sein die Daten der Brötje Heizung abzurufen
und auch zu verändern. Ob es dann über IPS möglich ist weiß ich noch
nicht. Die Info ist von einem Brötje Ingenieur.
Quelle http://www.ip-symcon.de/forum/threads/20454-Brötje-Heizung-an-IPS
Hallo zusammen,
> Aufbau ist CL+ -- 100 Ohm Widerstand -|- CL-/GND. Zwischen CL-/GND und> Widerstand einen NPN-Transistor (ich habe 2N2222), der dann die Leitung> auf 0 zieht.
Was mich sehr interessieren würde - wie seit Ihr auf die 100 Ohm
gekommen.
Hier geistert auch die andere Schaltungen mit den Optokopplern rum, bei
der (wenn ich alles richtig verstanden habe), CL+ direkt auf CL-
runtergezogen wird.
Dabei währe mit eher unwohl. Aber wieso wird hier 100 Ohm genommen.
Wieso nicht 50 oder 200. Woher weiss man wie stark man belasten
darf/soll.
---------------------------------
Was ich z.Z. absolut faszinierend finde.
Ich mache seit eingen Jahren im Bereich der Yachtelektronik mit
dem SeaTalk Bus rum. Und wie ich mir so Eure Erfolge hier anschaue,
da fällt mir auf dass ich anscheinend meine SeaTalk
Anbindungsschaltung 1:1 verwenden kann und auch einen großen
Teil der Software verwenden kann.
SeaTalk ist auch ein 4800 Baud Bus, benötigt auch ein
Kollisionserkennung etc.
Ok - dort gibt es 9-Bit statt 8 Bit und kein CRC, aber die
Hardware sieht für mich sehr ähnlich aus.
Hi,
Frank W. schrieb:> Was mich sehr interessieren würde - wie seit Ihr auf die 100 Ohm> gekommen.
Ein Wort - Angstwiderstand :) Ich wollte dem Transistor nicht
überlasten.
Der SeaTalk sieht ja echt ähnlich aus. Aber bei dem geringen HW-Aufwand
lohnt sich das Equipment kaum... außer man hat es eh rumliegen. Ob damit
natürlich wirklich etwas funktioniert (Software gibt es hier ja
nicht...) wage ich nicht bewerten zu können.
Anbei mein Skript mit den wichtigsten Daten. Viel Spaß damit.
Auch ein Log des Busses - vorn ist ein Unix-Timestamp.
@UH868
Danke für die Texte. Ja, es gibt den LPB-Webserver. Für viel Geld. Daher
diese Seite ;-)
Das Skript sollte genügen, um es auf PHP zu migrieren - da wäre das
Ganze auch simpler im Aufbau. Viel Spaß beim Übersetzen. Wäre vielleicht
ganz gut, wenn du diesen Thread im Kommentar in deinem Skript erwähnen
würdest ;-)
Grüße
Sascha
Hi Sascha, klar mache ich das.
momentan überlege ich noch wie ich die Hardware LPB<->USB baue und was
ich genau brauche. Und wie ich USB auslese am PC.
Gruß Uwe
@ Sascha K.
> Ein Wort - Angstwiderstand :) Ich wollte dem Transistor nicht> überlasten.
:-) Ok. Gute Antwort. Ich hätte es auch nicht einfach ohne
Strombegrenzung "kurzschliessen" wollen.
> Der SeaTalk sieht ja echt ähnlich aus. Aber bei dem geringen HW-Aufwand> lohnt sich das Equipment kaum... außer man hat es eh rumliegen.
Well - wenn wir mit der einfachsten Schaltung anfangen, dann ist die
sicher nicht komplizierter als die Schaltungen hier.
Siehe :
http://www.gadgetpool.de/nuke/modules.php?name=News&file=article&sid=20
Siehe : http://www.thomas-knauf.de/rap/seatalk3.htm#Uni
Die Dinger die ich mache haben halt nen eingenen AVR, der das Protokoll
entschlüsselt und sich z.B. beim senden um die Kollisionüberwachung
kümmert.
> Ob damit> natürlich wirklich etwas funktioniert (Software gibt es hier ja> nicht...) wage ich nicht bewerten zu können.
Ich auch nicht.
Ich werde morgen mal meine Hardware einfach ausprobieren.
Ich sage gerne Bescheid was rausgekommen ist, wenn's interessiert.
Die Software ist natürlich verfügbar - aber hier geht's ja nicht um
SeaTalk und Nmea. Da interessiert hier höchstens der "Netzwerk Teil".
Und wenn's funktionieren sollte, stelle ich es natürlich zur Verfügung.
Danke für Deine Scripts
Moin Sascha,
Sascha K. schrieb:> DC 80 7F 17 02 05 00 02 19 01 FF 00 00 FF FF FF FF FF FF 00 0F 0F FB> Außen: 7.98437>> Berechnung analog Innentemperatur:> Bytes 10+11 von HEX in Dezimal umwandeln ("01FF"=>511) und durch 64> teilen (511/64=>7,984375°C). Ebenso ist hier noch offen, wie die> negativen Zahlen dargestellt werden.
Negative Temperaturen: Könnte ein ganz normaler "signed Integer(16bit)"
sein.
Wenn das höherwertigste Bit gesetzt ist, ist der Wert negativ, dann
65536 vom Dezimalwert subtrahieren.
Beispiel:
FE01 => 65025 => 65025-65536 = -511 => -511/64 = -7.98437
//Niffko
@UH868
> momentan überlege ich noch wie ich die Hardware LPB<->USB baue und was> ich genau brauche. Und wie ich USB auslese am PC.
Ich will die Tage mal einen USB<->BSB-Wandler zeichnen. Den würde ich
dir dann empfehlen ;)
Zum passiven Mitlesen - was ja erstmal reichen sollte - nimm einfach wie
oben beschrieben einen USB-UART und den Spannungsteiler.
Am PC auslesen - auf Windows? Mh. Kleines VB-Skript? Aber wenn PHP eh
zur Verfügung steht, nimm doch phpserial
(http://code.google.com/p/php-serial).
@ Frank W.
Da hast du Recht mit dem geringen Aufwand. Kurz überflogen würde ich
auch sagen, dass das passt - wobei ich jetzt nicht die logischen Level
geprüft habe.
Wie passiert denn auf dem SeaTalk eine Arberitierung oder
Kollisionserkennung? CSMA/CA vielleicht? Kannst du mir da ein wenig
Infos geben?
@ Niffko
Danke - das sieht verlockend gut aus. Wie bist du darauf gekommen?
Ich habe auch angefangen, den BSB auf einen Arduino zu packen und
nebenher laufen zu lassen. Anbei mein erster Prosa-Code, der bestimmt
noch nicht kompiliert.
Ist halt nicht viel zu tun auf dem AVR aber der Raspberry hat mit dem
Skript und dem Java-Gelumpe nebenan schon gut zu tun - auch weil einige
Daten sehr häufig (Status) kommen.
Danke an alle :)
Sascha K. schrieb:> Da hast du Recht mit dem geringen Aufwand. Kurz überflogen würde ich> auch sagen, dass das passt - wobei ich jetzt nicht die logischen Level> geprüft habe.
Logik Level und Spannungen passen. (Zumindest an meiner Heizung. Habe es
gestern mit Oszi gemessen )
> Wie passiert denn auf dem SeaTalk eine Arberitierung oder> Kollisionserkennung? CSMA/CA vielleicht? Kannst du mir da ein wenig> Infos geben?
Nun - der Bus ist ein wired-or. Wer eine "1" senden will, der zieht den
Bus auf < 7 Volt.
Soweit ich gestern gemessen habe, wird der Bus bei meiner Heizung auf 0
Volt runtergezogen.
Nun - Ein Teilnehmer will senden :
Er wartet 10/4800 Sek ab, lauscht und schaut ob der Bus in dieser Zeit
von jemand anderem benutzt wird. Sprich ob der Bus in dieser Zeit mal
auf 0 runtergezogen wurde. Wenn ja - mit den warten neu anfangen.
Wenn nicht wird das erste Bit gesendet. ( Startbit )
Jedes gesendete Bit wird ( wegen Bus ) ja sofort auf der Empfangsleitung
wieder ankommen. Man schaut nach, ob das gesendetet Bit mit dem
empfangenen Bit übereinstimmt.
Wenn ich eine "0" sende - also den Bus auf High lasse, dann will ich
sehen, dass der Bus weiterhin auf High ist. Sollte ein anderer
Teilnehmer in dieser Zeit eine "1" senden - also den Bus herunterziehen,
dann höre ich sofort auf mit dem Senden und fange oben wieder an.
Danach folgen nach gleichem Muster die folgenden Bits, Bit 7..0, Parity
und Stop Bit.
Ich habe das auf einem AVR mit Software-Uart gemacht.
Damit kann eine Kollision sofort erkannt werden, da ja jedes einzelne
Bit überwacht wird. Wenn man den Hardware-Uart verwenden würde, dann
würde ich den Unterschied gesendetet Daten/empfangene Daten erst nach
einem ganzen Byte erkennen können.
Halbwegs verständlich ?
UH868 schrieb:> Du meinst diese Zeichnug, da fehlen aber noch ein paar Daten.>> Gruß Uwe
Hallo Uwe,
ich habe Niobos auf dest-unreach.be nach den Werten gefragt und in der
Zeichnung ergänzt
Gruß
Sebastian
Sascha K. schrieb:> @ Niffko> Danke - das sieht verlockend gut aus. Wie bist du darauf gekommen?
Bitte, gern geschehen ... komme vom Buderus-Thread nebenan, wir hatten
das Thema schon durch.
Wenn man direkt auf dem AVR parst, kann man sich die Rechnerei natürlich
sparen ... hast du ja in bsb.c auch schon entsprechend umgesetzt.
//Niffko
Auch wenn Weihnachten schon war... anbei ein kleines Arduino-Sketch samt
Aufbauanleitung und einer kleinen Library, die das Empfangen und Parsing
übernimmt.
Die Klasse BSB stellt in den Attributen T_* die verschiedenen
Temperaturen zur Schau und state beinhaltet den Status der Heizung.
Im Auslieferungszustand erscheint nach jeder empfangenen Nachricht "GOT
MESSAGE". Wenn diese erkannt/geparst wurde, erscheinen die Raum und
Außentemperaturen.
Checksumming u.a. ist nicht implementiert.
Bitte lasst, solltet ihr das Werk weiterverwenden, die Header erhalten.
Danke.
Bis dahin,
Sascha
@Frank
Eine gute Basis für deine Visu ;)
Nachtrag:
Im Ordner Libraries ist die ebenfalls mit Arduino ausgelieferte
SoftwareSerial. Bitte die von Arduino umbenennen und diese nutzen. Diese
geht mit den 8E1 "korrekt" um, sprich sie ignoriert das Parity bit ;-)
Sascha K. schrieb:> Auch wenn Weihnachten schon war... anbei ein kleines Arduino-Sketch samt> Aufbauanleitung und einer kleinen Library, die das Empfangen und Parsing> übernimmt.> Die Klasse BSB stellt in den Attributen T_* die verschiedenen> Temperaturen zur Schau und state beinhaltet den Status der Heizung.>> Im Auslieferungszustand erscheint nach jeder empfangenen Nachricht "GOT> MESSAGE". Wenn diese erkannt/geparst wurde, erscheinen die Raum und> Außentemperaturen.>> Checksumming u.a. ist nicht implementiert.>> Bitte lasst, solltet ihr das Werk weiterverwenden, die Header erhalten.> Danke.>> Bis dahin,> Sascha>> @Frank> Eine gute Basis für deine Visu ;)>> Nachtrag:> Im Ordner Libraries ist die ebenfalls mit Arduino ausgelieferte> SoftwareSerial. Bitte die von Arduino umbenennen und diese nutzen. Diese> geht mit den 8E1 "korrekt" um, sprich sie ignoriert das Parity bit ;-)
@Sacha
Schon gedownloadet.:-)
Du bist mein Held des Jahres 2012. Vielleicht wage ich mich dann ja doch
nächste Jahr daran.
Danke, danke, danke!
Sascha K. schrieb:> Auch wenn Weihnachten schon war... anbei ein kleines Arduino-Sketch samt>> Aufbauanleitung und einer kleinen Library, die das Empfangen und Parsing>> übernimmt.
Danke, für deine Mühe.
Momentan weiß ich nur noch nichts damit anzufangen. Arduino habe ich
gefunden es ist ein uP-System.
Wo finde ich die Aufbauanleitung? Was brauche ich noch dafür?
Wenn ich es richtig verstehe Arduino irgendwie an meine Brötje Heizung,
Arduino übernimmt die Auswertung der Signal, und stellt mir diese dann
zu Verfügung, wie kommen diese dann in den PC.
Danke für deine Infos, Gruß Uwe
UH868 schrieb:> Wenn ich es richtig verstehe Arduino irgendwie an meine Brötje Heizung,> Arduino übernimmt die Auswertung der Signal, und stellt mir diese dann> zu Verfügung, wie kommen diese dann in den PC.>> Danke für deine Infos, Gruß Uwe
Der Arduino hat ja auch eine eigene IDE und die hat einen Serial
Monitor. Da kannst du dir das alles ausgeben lassen.
Hier findest du alles:
http://arduino.cc/en/Tutorial/HomePage
Du kannst aber, wenn du C oder C++ kannst, auch das in der IDE
verwenden.
Hallo Zusammen,
Habe selbst eine Brötje Gastherme und bin daran interessiert verschiedne
Daten in IP-Symcon zu loggen, bzw. auch damit zu senden.
Ich hatte mir mitte November den von Helmut ins spiel gebrachten ebus
adapter gebaut und die ersten Daten mitgeloggt. Bin allerdings nicht
wirklich schlau daraus geworden.
Dank des Links von erik zu dest-unreach und der tollen Arbeit von Sascha
habe ich jetzt die ersten sinnvollen Daten in IP-Symcon drin.
Leider mußte ich schnell feststellen, dass ohne auf dem Bus zu senden,
das alles recht beschränkt ist. Ich bekomme immer nur alle 10 sekunden
den Wert dem im Display der
Bedienung angezeigt wird / Brenner an und aus, einen Zeitstempel sowie
einige Status Meldungen die ich noch nicht richtig entziffern konnte.
Zum Zeitstempel, es scheinen Jahr (ab 1900), Monat, Tag, Stunde, Minute,
Sekunde darin zu stecken, sieht dann als date funktion in php so aus:
date("r",mktime($arr[14],$arr[15],$arr[16],$arr[11],$arr[12],($arr[10]+1
900)))
Das IP-Symcon script hänge ich mal an, kurzbeschreibung ist im Skript.
Im Moment werden Länge sowie CRC geprüft und die Kommandos die ich
soweit identifizieren konnte verarbeitet.
Im Moment bin ich am sendeskript, Ziel wäre das RGT (1 und 2) zu
simulieren und hier vor allem auch die aktuelle Raumtemperatur and die
Heizung zu senden. Da ich leider kein RGT habe,
bin ich mir nicht so sicher wie die Daten aussehen müssen.
Wenn jemand die folgden daten mal loggen könnte wäre ich sehr dankbar:
RGT als RGT1 konfigurieren
RGT als RGT2 konfigurieren
RGT1 zum steuern von Heizkreis 1 konfigurieren
RGT1 zum steuern von Heizkreis 1+2 konfigurieren
Ich hoffe, dass ich daraus schlau werde, wie das Paket aussehen muß um
ein RGT1 und ein RGT2 zu simulieren und die Raumteperaturen auf den BUS
zu senden.
Danke and alle die hier mithelfen.
Grüsse
Michael
ACHTUNG
Gestern habe ich mir den AVS zerschossen beim Versuch zu senden. Der Bus
ist eigentlich kurzschlussfest (wird ja auch detektiert) aber scheinbar
ist irgendwas schief gelaufen. Nach Tausch eines durchgeknallten
Widerstands lief es wieder (gut, dass der RGT gleich aufgebaut ist).
Also: ACHTUNG
@Michael:
Mache ich heute mal. Zufällig hatte ich gestern im Systemhandbuch
gesehen, dass der RGT ja quasi noch ein Programmiermenü hat
(Präsenztaste >3 Sekunden drücken).
Vielleicht ist wegen dem Problem oben eine Skizze vom Sende/Empfangsteil
des AVS nicht verkehrt. Mal schauen wann ich die Muse dazu finde...
Ganz nebenbei finde ich es toll, was hier so aus der Forschung
geschieht. Inzwischen schon bei IPSYMCON :-)
Grüße
Sascha
@Sascha
soll ich Dir mal einen E-Bus-Adapter zukommen lassen?
Bringt uns alle weiter Deine Ardunio-Geschichte, da helfe ich gerne !!
Mailadr findest Du im IPSymcon-Forum.
Ich hätte auch noch ein Platinchen für OpenTherm, da ich nix mit E-Bus
habe, kann ich selber nix testen.
Gruß Helmut
Das motiviert mich nicht gerade das Senden zu testen :-(
Wollte nicht unbedingt die Kiste zerschießen.
@Sascha:
Wie hast du denn die Sendestufe realisiert?
Ich habe mein Empfansteil auf Basis der Plans von Tony aus dem ebus
Thread aufgebaut:
Beitrag "ebus protokoll mitschnitt bei einem Wolf Heizkessel"http://www.mikrocontroller.net/attachment/85171/schaltung.gif
und dann noch einen usb - seriell (ttl) wandler drangehängt.
Den Sendeteil habe ich noch nicht aufgebaut, wollte aber den Plan
verwenden und wie von Helmut beschrieben eine kleinere Z-Diode nehmen.
Mir ist nur unklar, ob das Senden auch mit den invertierten Daten
klappt. script zum CRC berechnen und invertieren über IP-Symcon habe ich
zumindest für einen Test soweit fertig. (nur traue ich mich jetzt
irgendwie nicht mehr....)
Grüße
Michael
Ich hatte auch schon eine Platine vorgestellt, die eine
Konstantstromquelle in der Sendestufe hat.
Vorteil: Es fließt ein definierter Sendestrom. Müßte auch im
IPSymcon-Forum irgendwo sein... ;-).
Gruß Helmut
@ Michael
Adresse RGT:
RGT1 86
RGT2 87
Das Setzen auf HK1 / HK2 ist im Protokoll anbei. Falls du es genauer
haben willst, schreib am Besten einen definierten Ablauf, dann kann ich
den nachvollziehen und im Log kommentieren ;-)
@ Helmut
Danke für das Angebot :)
Ich denke - wobei ich es nicht erklären kann - es lag am Optokoppler.
Ich wollte von der weiter oben gezeichneten Sendeschaltung auf eine
"sicherere" wechseln. Dabei habe ich es zum Empfang beim Spannungsteiler
belassen und über einen Optokoppler CL+ und CL- verbinden wollen.
Hat auch irgendwie geklappt - aber die Daten waren kompletter Müll...
ich mache mich mal ans Aufzeichnen der Stufe im AVS ;-)
Grüße
Sascha
@Sascha:
Vielen Dank für die schnelle Rückmeldung. Damit bestätigt sich meine
Vermutung, dass die 87 das RGT2 ist.
Auf dein Angebot komme ich gerne nochmal zurück, im Moment reicht mir
das so. Ich gehe davon aus, dass default RGT1 für HK1 und RGT2 für HK2
genommen wird. Die Einstellung (wechsel auf HK2) wird anscheinend in 2
Paketen an das Grundgerät geschickt. Zurück kommt jeweils ein "ACK"
Paket
1357229557 DC 86 00 0D 03 3D 2D 05 74 01 01 A1 7A
1357229557 DC 80 06 0B 04 2D 3D 05 74 58 5F
1357229557 DC 86 00 0E 03 3D 2D 05 8E 01 05 00 C9 AD
1357229557 DC 80 06 0B 04 2D 3D 05 8E 16 0A
In den regelmäßigen Raumtemperatur Meldungen ist dann wirklich nur die
Temperatur drin.
Sollte also reichen, die Daten einmal als RGT1 und einmal als RGT2 für
die beiden HKs zu senden.
An deiner Zeichnung der AVS Stufe wäre ich sehr interessiert.
Ich werde mich jetzt erstmal damit beschäftigen das Menü abzuklappern
und die Parameter alle zuordnen.
Für die Pakettypen habe ich bislang (nach meinem Verständnis):
02 - Info Message
03 - Setzen eines Parameters, wird mit
04 - "ACK" bestätigt
06 - auslesen eines Wertes, und es kommt
07 - Antwort mit Wert
Grüße
Michael
Hallo Helmut,
das mit dem E-Bus-Adapter kingt für mich ganz interessant.
Wie ist den dort der aktuelle Stand, wie sieht die Schaltung aus?
Gruß
Sebastian
Hi,
@ Michael R.
Du redest vom Feld TYP1, Byte 5, richtig? Hier war mir auch schon eine
Relation aufgefallen, aber du bist schon echt sehr weit. Und es sieht
plausibel aus - hier mal Beispiele:
02 - Kommt vom Regler (Zeit, AußenT), Raumgerät (Temperatur)
03 - Zeitprogramm, Sollwert ändern
04 - nach jeder Änderung mit 03
06 - Status WP, Wertabfrage über i-Taste
07 - Antwort mit Wert
Danke für die gute Arbeit - sehr hilfreich :)
Übrigens muss das letzte Byte ein Stuff-Byte sein, damit die Prüfsumme
passt. Online unter
http://www.lammertbies.nl/comm/info/crc-calculation.html zu prüfen:
Telegramm in Textfeld, HEX auswählen, prüfen drücken, "CRC-CCITT
(XModem)" muss 0x0000 sein.
Wie dieses berechnet wird um komplett eigene Telegramme zu bauen, habe
ich leider noch nicht gefunden - sollte aber irgendwie über XModem zu
finden sein.
@ Sebastian G.
Helmut möchte mir einen zusenden. Den kann ich dann ja mal am
reparierten AVS testen und versuchen den Regler zu emulieren, so dass
der AVS denkt er hängt am richtigen Bus.
@ Helmut
Kannst du kurz was zum Adapter schreiben, wie der funktioniert oder auf
einen Post verweisen?
So wie ich das sehe, ist die Konstruktion aus den 2 Dioden+Z-Diode da,
um einen Low-Pegel mit klarer Flankensteilheit zu erkennen (haben die
Dioden eine Funktion beim Senden?). Der Poti macht das Gleiche wie mein
Spannungsteiler und bringt die Bus-Spannung auf ein "erträgliches"
Niveau.
Der 78L05 stellt V+ für den NAND - aber warum wird der NAND so oft
benutzt? Warum gibt es eine Kopplung V+ & VBUS und dann nochmal auf V+?
Warum müssen zwischen 2-3V am Schleifer anliegen / darf der Bus nicht
auf 0V gezogen werden?
Ich probiere halt rauszufinden, warum der AVS abgelebt hatte ;) Ich
vermute, dass der Kurzschluss - der ja eigentlich zulässig ist - ein
Bauteil an der Toleranzgrenze zerstört hatte. Der restliche Bus läuft ja
ohne Probleme weiter.
Grüße Sascha
Danke Michael, aber die CRC-Prüfung habe ich schon hinbekommen. Mir geht
es um das Ausgleichs-Byte, dass dafür sorgt, dass die Prüfsumme am Ende
passt ;)
Oder habe ich was übersehen... ;)
Sascha K. schrieb:> @ Helmut>> Kannst du kurz was zum Adapter schreiben, wie der funktioniert oder auf>> einen Post verweisen?>> So wie ich das sehe, ist die Konstruktion aus den 2 Dioden+Z-Diode da,>> um einen Low-Pegel mit klarer Flankensteilheit zu erkennen (haben die>> Dioden eine Funktion beim Senden?). Der Poti macht das Gleiche wie mein>> Spannungsteiler und bringt die Bus-Spannung auf ein "erträgliches">> Niveau.>> Der 78L05 stellt V+ für den NAND - aber warum wird der NAND so oft>> benutzt? Warum gibt es eine Kopplung V+ & VBUS und dann nochmal auf V+?
Die Dioden und die Z-Diode ist nur zum Senden da.
Ist der Transistor leitend, also Befehle gesendet, wird die Busspannung
auf den Wert Diodenspannung plus Z-Diodenspannung runter gezogen.
Die Spannung an Poti ist die Schwellspannungserkennung zu High und Low
der E-Bus-Spannung.
Andere Schaltungen machen Das mit OP's.
Meine Schaltung ist unter anderen hier, wobei der 7805 ein 78L05 werden
sollte:
http://ebus.webhop.org/twiki/bin/view.pl/EBus/EBusKonverter
Fertige Adapter im Hutschienengehäuse gibt es bei Andreas:
http://eservice-online.de
Gruß Helmut
@Sascha:
was meinst du mit ausgleichsbyte?
Wenn ich mal ein beispiel aus deinem log weiter oben nehme:
Frage:
SOT SRC DST LEN TYP XX XX XX XX [CRC]
DC 8A 00 0B 06 3D 05 07 B0 A4 8C
Antwort:
SOT SRC DST LEN TYP XX XX XX XX [Data] [CRC]
DC 80 0A 0D 07 05 3D 07 B0 00 19 6D 58
wobei XX XX XX XX scheinbar immer nach dem Muster funktioniert, dass die
ersten beiden bytes zwischen abfrage/setzen Parameter und Antwort
gedreht werden. (Soweit ich das bis jetzt gesehen habe ist die 3d auch
immer gleich, das andere byte ist mal 05, mal 2d...)
also Abfrage
3D 05 07 B0 liefert als Antwort
05 3D 07 B0
Ich weis nicht was 3D 05 07 B0 fuer ein Wert ist (was zeigt dein
Display im Standard immer an?), aber z.B. habe ich immer fuer die
Aussentemperatur abfrage 3d 05 05 21, Antwort ist immer 05 3d 05 21.
die letzen 2 bytes im Telegramm sind dann immer der CRC wert.
Meine Idee war jetzt die 3 Byte (05 07 B0) den Namen, bzw. Nummern aus
dem isr Handbuch zuzuordnen.
Gruesse
Michael
schnell ein Nachtrag, bevor's schief geht:
Mein, und auch der fertige Adapter von Andreas, sind für die serielle
Schnittstelle gebaut.
Wenn jemand an einen µProzessor damit will, muß der Max-Baustein raus
und
GANZ WICHTIG
der 4011 muß vom µP so mit Spannung versorgt werden, dass der Transistor
NICHT angesteuert wird, also es muß LOW an dem 4011 (Sende-Eingang)
sein.
Zum Üben reicht es wenn die Z-Diode oder der Transtistor nicht bestückt
wird.
Gruß Helmut
Hallo, an diese Platine RVA63.242/100 (Brötje)
Beitrag "ALA1 im PLCC Gehäuse analog/digital Wandler?"
kann auch ein QAA70 angeschlossen werden. Vielleicht kann jemand helfen.
Ich will die Protokoll Analyse nur nicht durcheinanderbringen. Darum
habe ich ein extra Thread gestartet.
Viele Grüße Herbert
Hallo,
ich habe jetzt mal die Schaltung der Empangsstufe (mit dem
Spannungsteiler und Transistor) aufgebaut und an meiner Heizungsregelung
an die BSB-Steckkontakte CL+ und CL- angeschlossen und dann mit HTERM
(Baud: 4800, Data: 8, Stop: 1, Parity: Odd) gelauscht, ohne Ergebniss
:-(
Was mache ich falsch?
Gruß
Sebastian
@ Sebastian
Schade, dass es nicht auf Anhieb geklappt hat. Probier doch erstmal nur
mit Spannungsteiler und ohne Inverter. Da sollte zumindest etwas kommen.
Ebenso kannst du mit der Parity Odd/Even herumtesten.
@ Herbert
Der QAA70 hat m.W.n. ein anderes Protokoll - die Hardware war glaube ich
aber ähnlich. www.marjorie.de/heizung/heizung20.htm
Nebenbei interessant:
Ich habe mir mal einen anderen AVS geholt für Gas-Heizungen
(AVS37.294/184). Die Einheit funktioniert - bis auf die Uhrzeit. Diese
will einfach nicht syncronisieren. Dafür gibt's ein Telegram für
Handbetrieb - schicke ich später vorbei.
Sascha
@Sascha:
Ich habe einen Kessel, den gab es zuerst mit einer alten
Steuerung+QAA70. Seit einigen Jahren gibts den gleichen mit der ISR
Plus. Wenn ich meine Änderungen so wie gedacht nicht hinbekomme, dann
tausch ich evt. einfach die Steuerung und die Adapterplatine gegen die
aktuelle Version. Bedienungsanleitung für die ISR Plus habe ich schon.
Mein QAA70 habe ich auch erst gestern bekommen. Muß erst noch Löcher
durch die Decke bohren usw. dauert also noch etwas.
Viele Grüße Herbert
Hallo Zusammen,
ich habe mal die Parameter aus dem isr Handbuch in ein Excel kopiert und
bin dann mal alle Werte an meiner Gas-Heizung durchgegangen und habe die
Bytes 6/7/8/9 aus den Telegrammen notiert. (Immer aus sicht der Heizung,
die bytes 6/7 werden beim Setzen, oder Abfragen über AVS/RGT gedreht)
einige Parameter (Nummern größer 10000 habe ich mir selbst definiert, da
die nicht im Handbuch sind und keine im Display angezeigte nummer
haben.)
Einige mit Nummer habe ich in der Liste auch ergänzt die waren im
Handbuch nicht drin.
Ich habe das jetzt genutzt um meinem IP-Symcon script die ganzen
Parameter in einem Array mitzugeben. (Aktuell habe ich keine Telegramme
mehr die ich nicht zumindest identifizieren kann)
Vielleicht helfen die Daten dem ein oder anderen weiter die Telegramme
auszuwerten.
Nächster Schritt ist jetzt zu schauen wie die jeweiligen werte in der
Daten hinterlegt sind.
@Sascha:
Gibt es Neuigkeiten zur Sendestufe? Bin echt heiß darauf zu senden, trau
mich aber nicht ran... :-)
Grüße
Michael
Sascha K. schrieb:> @ Sebastian> Schade, dass es nicht auf Anhieb geklappt hat. Probier doch erstmal nur> mit Spannungsteiler und ohne Inverter. Da sollte zumindest etwas kommen.> Ebenso kannst du mit der Parity Odd/Even herumtesten.
Du meinst den Spannungsteiler direkt an RXD und CL- an GND?
@Sebastian
Genau. Aber bloß nicht ohne Widerstand direkt an RXD!! Falls du Lust
hast, könntest du meine Aufzeichnung die gleich folgt einmal zeichnen?
Ich habe leider immernoch nur GSM :((
@ Michael
Toll gemacht :) Vielleicht ganz nützlicher Hinweis - mein RGT zeigt bei
einigen Einstellungen nur eine Zahl an während der AVS da Klartext
macht. Evtl. geht die angezeigte Zahl sogar über den Bus. Muss mal
raussuchen welche Parameter das waren.
Zur Sendestufe:
Hier der Plan vom AVS abgezeichnet und unterteilt in "Eingangsfilter",
"Sendeteil" und "Empfangsteil"
Eingangsfilter:
CL+/CL- sind die direkten Eingänge, die auch an die Servicebuchse vorn
1:1 durchgeleitet werden (Pin2+3). Die Diode links ist lt. Beschriftung
18A 0AA, den Kondensator kann ich nicht messen, wird aber vermutlich
zum Filtern sein.
1
CL+ --------- CL+1
2
| |
3
_ _
4
^ _
5
| |
6
CL- --------- CL-1
Empfangsteil:
Hier verwendet auch Siemens einen Spannungsteiler :) Dieser ist
allerdings größer ausgelegt und eine Darlington-Schaltung ist
nachgelagert um die niedrigen Pegel wieder verwenden zu können. Hier
würde mich interessieren, warum erst so niedrig gepegelt wird.
RCV ist dann der PIN am uC.
Die Transistoren sollten PNP sein und sind in ASCII schwer zu zeichnen
;)
1
CL+1 --
2
|
3
100k -GND--
4
| / | |
5
>----| / |
6
| \-| 100k
7
12k \--|----- RCV
8
|
9
CL-1 --
Sendeteil:
Ein N-Channel FET
(http://www.datasheetcatalog.org/datasheet/siemens/BSP318S.pdf) zieht
die ganze Leitung auf den Pegel der es sein soll. Die Ansteuerung diesen
passiert über einen Transistor und 2 Widerständen.
Mit Gate, Drain, Source kenne ich mich nicht aus und rate einfach mal.
Sascha K. schrieb:> Hier> würde mich interessieren, warum erst so niedrig gepegelt wird.> RCV ist dann der PIN am uC.
Nur ein bescheidener Gedanke dazu: Vielleicht weil der sonst zu viel
Strom "klauen" würde?
Man Jungs! Ich kann dem Ganzen hier nur noch marginal folgen, weil ihr
mir Lichtjahre voraus seid, aber das ist so spannend bei euch mit zu
lesen.
Hoffentlich kriege ich das mit der Heizung dann im nächsten Jahr hin,
wenn ihr so schöne Vorarbeit geleistet habt.
Aber leider glaube ich, wenn ich realistisch sein will, dass das noch
bis 2017 dauert, bis ich so was kann.
@Sascha:
Bin mir nicht sicher ob ich deine Zeichnung richtig verstehe.
Kannst du mal über die angehängte Zeichnung schauen, ob das so passt?
(nur das Sendeteil im Moment)
Ich denke source und drain gehören in deiner Beschreibung gedreht.
Grüße
Michael
@Michael & Sebastian
Dank euch beiden für die Zeichnungen.
Zum besseren Verständnis vielleicht noch eine kleine Anmerkung:
Die V+ wird im Gerät aus CL+ generiert. Wie hoch diese ist, möchte ich
nicht im frisch reparierten Gerät messen ;) Ich gehe aber von 1,8V < V+
< 5V aus.
Lt. Datenblatt des BSP318 liegt CL+1 an Pin 2. Pin 3 ist GND, Pin 1 ist
der Steueranschluß. Ich weiß jetzt nicht, wie die Pins heißt - mit FETs
habe ich noch nichts entwickelt.
@ Michael
Sebastian hat alles prima verstanden. Ich denke, wir sollten seine
Zeichnung als weitere Referenz nehmen. Trotzdem herzlichen Dank :)
@Sebastians Zeichnung
1. Ich weiß nicht, ob die Reihenfolge entscheidend ist, aber der
Eingangsfilter liegt im Gerät direkt an den Klemmen.
2. Q4 in der Zeichnung ist bei dir NPN. Ich gehe auch von NPN aus, da
über V+ geschaltet wird. R5 ist richtig in der Datenleitung platziert
sehr gut
Danke euch nochmal für die Zeichnungen.
Ich werde in den nächsten Tagen leider keine Zeit zum Basteln finden.
Möchte jemand versuchen an den Bus zu senden?
Grüße
Sascha
Frank W. schrieb:> Ich habe das auf einem AVR mit Software-Uart gemacht.
Könntest du mir diesen Teil deines AVRs zur Verfügung stellen ;-)
Ich kriege die Logik zur Arberetierung nicht hin, weiß aber auch nicht
wo es hängt.
Deine Ausführung zum Thema CSMA/CA waren echt hilfreich, vielen Dank.
Grüße
Sascha
Sascha K. schrieb:> Die V+ wird im Gerät aus CL+ generiert. Wie hoch diese ist, möchte ich> nicht im frisch reparierten Gerät messen ;) Ich gehe aber von 1,8V < V+> < 5V aus.
Wie wird den V+ erzeugt? Schaltung?
Sascha K. schrieb:> 1. Ich weiß nicht, ob die Reihenfolge entscheidend ist, aber der> Eingangsfilter liegt im Gerät direkt an den Klemmen.
Ja das macht schon sinn direkt an den Klemmen, habe dass gestern Abend
falsch gelese ;-)
Gruß
Sebastian
Sascha K. schrieb:> Könntest du mir diesen Teil deines AVRs zur Verfügung stellen ;-)
Sag mir kurz, für welchen uC Du das brauchst.
Ich habe Versionen für Atmega32, Atmega128, Atmega1284p.
( At90Can128 und Atmega644 müsse ich erst nachschauen )
Gruss
Frank
Wollte mal mein Glück mit dem Senden probieren und habe den Sendeteil
des e-bus Adapters aufgebaut. Das Ergebnis war, dass auch das Empfangen
nicht mehr richtig funktioniert hat :-(
Beim mitloggen habe ich zwar die Anfragen vom AVS noch sauber gesehen,
die Antworten waren allerdings Schrott. Der BUS lief zwar ohne Probleme
weiter und das AVS hat die Daten korrekt angezeigt. Daher vermute ich
mal, dass die Versorgungsspannung (diese wird ja aus CL+ / CL- vom Bus
erzeugt) meines Adapters zu sehr einbricht und der dann nicht mehr
sauber funktioniert. Nach trennen der Verbindung von TXD (RS232-TTL /
USB Adapter) zum Widerstand läuft das Empfangen nun wieder.
Die 5V stattdessen vom USB Adapter zu nehmen habe ich mich bislang nicht
getraut.
Grüße
Michael
Zum Glück doch noch ein paar Minuten gefunden :-)
Sebastian G. schrieb:> Wie wird den V+ erzeugt? Schaltung?
Die Spannung wird im AVS abweichend vom QAA NICHT aus dem BSB
gewonnen, sondern über +12V generiert (PIN 1 vorne). Wenn mir meine
Augen und das Internet keinen Streich spielen, steht auf dem
generierenden IC "ABP". Google verrät dass das ein LM4040CIX3-2.5 sein
soll. Kann man denn daraus ein Gerät versorgen... soll ja ein Shunt
sein???
BTW, der uC ist ein "NEC d78f1145".
Frank W. schrieb:> Sag mir kurz, für welchen uC Du das brauchst.
Am Besten für den ATMEGA328. Ich denke, der ATMEGA32 tut's auch ;) Ist's
denn ASM oder C? C wäre mir lieber, da ASM bei mir immer so langsam im
Kopf läuft :-D
Michael R. schrieb:> Sendeteil des e-bus Adapters
Das Problem scheint zu sein, dass die Geräte nicht mit einem Störer
zurecht kommen können. Es darf nicht in der Übertragung
dazwischengefunkt werden. Ich verstehe nur noch nicht warum weil der Bus
ja für solche Szenarien ausgelegt ist....
Grüße
Sascha
Tach zusammen
Ich kann euch leider noch nicht so folgen, würde aber einen
RVS43.143 nebst AVS75 Display und passendem Verbindungskabel
zur Verfügung stellen, um das mal anzuschieben....
Somit braucht derjenige nicht am lebenden Objekt spielen.
Es soll ja noch kälter werden :)
Der RVS43.143 ist der ISR-BCA Kaskadenregler,
gibbet dann allerdings ohne das Gehäuse.
Jemand?
Ich werde die hier zusammengetragenen Erkenntnisse in einem Wiki
zusammenschreiben. Ihr seid gern eingeladen, mit zu helfen.
Das Wiki befindet sich hier: http://www.wikihost.org/w/bsbrev
Ich habe mich nochmal an das Senden gewagt. Hierzu habe ich meinen ebus
Adapter ein wenig umgebaut. (Empfangen über festen Spannungsteiler
10k/30k, Versorgungsspannung kommt jetzt vom rs232 - USB wandler.
Zumindest ein Teilerfolg. Ich bekomme das gesendete Telegramm selbst
sauber zurück. Schaffe es aber nicht die Heizung zu einer Antwort zu
bewegen. Das die Bytes korrekt sind bin ich mir recht sicher, das zurück
empfangene Paket (Abfrage der Außentemperatur) sieht genauso aus wie das
Paket des AVS... aber es kommt einfach keine Antwort.
habe jetzt schon alles mögliche ausprobiert, aber irgendwie fehlen mir
die weiteren Ideen :-(
Habe es mit kleineren Z-Dioden, einem anderen USB/rs232 Adapter probiert
und versucht jeweils vor/nach der Übermittlung ein Break zu senden...
Grüße
Michael
Sascha K. schrieb:> Ich werde die hier zusammengetragenen Erkenntnisse in einem Wiki> zusammenschreiben. Ihr seid gern eingeladen, mit zu helfen.>> Das Wiki befindet sich hier: http://www.wikihost.org/w/bsbrev
Hab mich hier immer mal (kleinlaut) zu Wort gemeldet. Bitte sch reib das
so, dass auch jemand wie ich das einigermaßen nachvollziehen kann.
Ich hab ne ungefähre Vorstellung von dem was hier läuft, aber richtig
folgen kann ich euch schon ne ganze Weile nicht mehr.
Für mich ist das sehr interessant und ich wwürde mich freuen, wenn ich
da was von in ein bis zwei Jahren gebrauchen kann.
Danke für all eure Mühe. Ihr seid wirklich ein spitzen Team.:-)
Bin auf Sendung! :-)
und bekomme auch die erwarteten (und ersehnten) Antworten.
Der Rest ist jetzt nur noch ein bischen Fleißarbeit.
Das ebus sendeteil habe ich gegen einen n-kanal fet getauscht und schon
klappt alles. Ich werden später mal aufzeichnen wie der adapter jetzt
aussieht.
Grüße
Michael
@ Michael
Sehr gut. Ich bin auch gerade dabei die Parity-Berechnung und alles
schön in die Arduino-Lib zu packen. Das Senden hatte ich gerade versucht
und wieder "keine Verbindung" erhalten... hatte schon Angst, dass wieder
was hin ist - ist aber alles OK. Hatte nur nen Pull-Up am
Sende-Transistor.
Damit ich dich richtig verstehe: Dein Adapter ist der ebus-Adapter von
Helmut und den Sendetransistor samt der 3 Dioden hast du mit einem
n-Mosfet ersetzt?
Grüße
Sascha
@Sascha:
vom eBus Adapter sind eigentlich nur die NAND Gatter geblieben.
Die Empfangsstufe hat einen festen Spannungsteiler, die Versorgung
erfolgt über externe 5V aus dem USB/RS232 Wandler.
Die Sendestufe ist ein N-Kanal Mosfet (TTL) der direkt über das NAND
Gatter angesteuert wird. Der Mosfet ist zwar etwas überdimensioniert,
der war aber noch in der Bastelkiste :-)
Sascha K. schrieb:> Ich werde die hier zusammengetragenen Erkenntnisse in einem Wiki>> zusammenschreiben. Ihr seid gern eingeladen, mit zu helfen.
Werde mich gerne beteiligen, klasse Idee. Durch den Thread sieht ja
langsam keiner mehr durch der das ganze nicht verfolgt.
Sascha K. schrieb:> Vielleicht ganz nützlicher Hinweis - mein RGT zeigt bei>> einigen Einstellungen nur eine Zahl an während der AVS da Klartext>> macht. Evtl. geht die angezeigte Zahl sogar über den Bus. Muss mal>> raussuchen welche Parameter das waren.
Ja, scheint so zu sein, dass bei den Textparametern einfach von 1 an
durchnummeriert wird. Also nur etwas Fleißarbeit die Zuzuordnen.
Bei den Zahlen Parametern gibt es die /64 und *2 (scheint immer da zu
sein, wo ,5 werte möglich sind. Andere zahlen sind einfach 1:1 in hex.
Sascha K. schrieb:> Das Problem scheint zu sein, dass die Geräte nicht mit einem Störer>> zurecht kommen können. Es darf nicht in der Übertragung>> dazwischengefunkt werden. Ich verstehe nur noch nicht warum weil der Bus>> ja für solche Szenarien ausgelegt ist....
Kann ich nicht bestätigen, wenn ich "dazwischen quatsche" und
gleichzeitig Werte im AVS aufrufe, zeigt das nur ein wenig länger die
Sanduhr und holt sich den Wert nochmal. Meinen ersten Sendeversuch habe
ich mit der Adresse des AVS gemacht, das hat mir dann die "bimmel"
angezeigt, es erkennt also sofort das ein zweites device mit der selben
Adresse am Bus hängt. Läuft aber sauber weiter. Jetzt bin "ich" das RGT1
Schau bitte mal über die Schaltung, ich hoffe ich habe keine Fehler in
die Zeichnung gebaut.
Grüße
Michael
Michael R. schrieb:> Bei den Zahlen Parametern gibt es die /64 und *2 (scheint immer da zu> sein, wo ,5 werte möglich sind. Andere zahlen sind einfach 1:1 in hex.
Meinst du damit die Umrechnung vom angezeigten Parameter in die Bytes
6-9 im Telegramm? Das wäre ja toll, wenn man die einfach umrechnen
könnte. Eventuell gibt es eine "Grenze" und dass im unteren Bereich
nicht gerechnet werden muss und oberhalb nach deiner Formel... kann ich
mir aber nicht vorstellen - man will ja nicht 2 Methoden haben wollen.
Michael R. schrieb:> Kann ich nicht bestätigen
Habe auch das Gefühl, dass mein altes AVS einen Schuss hat - ein
kurzschlussfester Bus sollte bei Kurzschluss kein Gerät zerhauen können.
Naja - geht ja wieder ;)
Michael R. schrieb:> Schau bitte mal über die Schaltung
Kann zu so später Stunde keinen Einwand werfen - der sieht echt gut aus.
Ich muss mal nach nem FET in selbiger Kiste schauen ;-)
Zum Spannungsteiler:
Der Einwand, dass der "Original-Aufbau" weniger Strom zieht mag sein,
allerdings wird im Einfamlilienhaus der Bus nicht an die Grenze
getrieben - weder mit Buskabellänge noch Anzahl der Geräte. Daher sollte
der "Mehrverbrauch" durchaus praktikabel sein.
Grüße
Sascha
Sascha K. schrieb:> kann ich> mir aber nicht vorstellen - man will ja nicht 2 Methoden haben wollen.
Ich habe mich vielleicht etwas mißverständlich ausgedrückt. So wäre es
ja gemein :-)
Innerhalb eines Parameters ist die Berechnung eindeutig.
Aber z.B. bei Trinkwasserspeicher Parameter Schaltdifferenz 2.5°C
werden als Hex 00 05 übertragen.
Ein Aus Parameter als Ein 00 00 Aus 00 ff
Ist ein Parameter deaktiviert steht im ersten Datenbyte eine 01 statt
00. Z.B. Heizkreis2 / Reduziert anhebung Beginn zeigt bei mir im Display
---°C im Telegramm 01 fe c0. (Die beiden hinteren bytes bleiden dann
wohl auf dem zuletzt aktiven Wert stehen.)
Grüße
Michael
Das ist ja richtig geil - die Temperatur über den BSB setzen und dann am
Bediengerät angezeigt zu bekommen :-)
*Danke Michael für den mutigen Versuch und die Info wie der Adapter
auszusehen hat!!!!!!*
Seit heute wird der Heizstab in der Heizung nur noch "freigegeben" (also
konfiguriert) wenn es wirklich nötig ist. Die Reglung ist - was das
angeht - wirklich zu freizügig und starr.... oder ich und mein
Heizungsbauer blicken's nicht wie's richtig geht :-(
Ich schreibe in den nächsten Wochen mal alles zusammen und werde die
Arduino-Bibliothek erweitern, sodass ein einfaches bsb.getOutside reicht
um die Außentemperatur zu kriegen (Beispiel ;)
Wer also leicht auf den Bus will, sollte den USB-Adapter bauen und kann
mit jedem Terminal-Programm lauschen und senden. Wer mehr will sollte
vielleicht einen Arduino/AVR zur Hand haben und die Bibliothek nehmen -
da wird dann auch CSMA/CA (Danke Frank ;) und das Protokoll verarbeitet.
Grüße
Sascha
PS: Danke Numsi für das schnelle versenden und sowieso für die Geräte.
Ich habe ja schon geschrieben, dass ich mir einen RVS besorgt habe und
dann mal die LPB Kommunikation angehe.
PPS: Die Telekom... endlich wollen sie DSL schalten... ENDE JANUAR
freu *Drecksladen*. Dann geht's auch alles schneller ;-)
@Sascha:
Klingt als ob die Bastelkiste noch einen fet hergegeben hat :-))
Hab ich das richtig gelesen du benutzt einen atmega328? Da ich gerade
entdeckt habe, dass ich Arduino auch mit einem vorhandenen avr net-io
nutzen kann würde ich das doch glatt auch gerne mal ausprobieren. Glaub
da steckt im Moment ein 644 drin. Meine Idee wäre das invertieren, CRC
und CSMA/CA im AVR machen zu lassen und das dann z.B. wieder an die IP
Symcon zu hängen.
Habe bislang vergeblich versucht mich bei Wikihost anzumelden, bekomme
immer eine Meldung das etwas "wirklich schiefgelaufen ist" :-(
Bin gerade dabei mein IP Symcon script schön zu machen und die
entsprechenden Umrechnungen für die Paramter zu hinterlegen.
Die RGTs werden schon schön emuliert (Raumtemperaur) und die Heizung
weis nun endlich wie warm es in der Burg ist.
Grüße
Michael
Hi Michael,
hast du im IP Symcon Forum schon was geschrieben, da finde ich nichts.
Wer bist du da?
Hier komme ich momentan gar nicht so schnell mit. Wird Symcon nicht
überfordert wenn es dauernd die ganzen Daten mitlesen muß?
Gruß Uwe
Sebastian G. schrieb:> Sascha K. schrieb:>> @ Sebastian>> Schade, dass es nicht auf Anhieb geklappt hat. Probier doch erstmal nur>> mit Spannungsteiler und ohne Inverter. Da sollte zumindest etwas kommen.>> Ebenso kannst du mit der Parity Odd/Even herumtesten.>> Du meinst den Spannungsteiler direkt an RXD und CL- an GND?Sascha K. schrieb:> @Sebastian> Genau. Aber bloß nicht ohne Widerstand direkt an RXD!!
So habbe jetzt mal den Spannungsteiler (wie auch im Wiki 30k zu 10k)
aufgebaut und den Mittelpunkt an RXD und CL- an GND vom USB/RS232
Wandler gelegt.
Ohne Ergebniss :-(
Woran kann das liegen???
Gruß
Sebastian
@Uwe:
nein, habe bislang noch nichts im IP Sysmcon Forum geschrieben. Habe
mich erste gerade dort registriert. (Gleicher Beutzername wie hier)
Bislang spielt die IP Symcon ohne Probleme mit. Die meiste Übertragung
bezieht sich auf den Wert der aktuell im AVS angezeigt wird (1*Frage, 1*
Antwort alle 10 Sekunden)
Da steckt auch noch die meiste Arbeit was das Skript angeht, ich möchte
das ja so gestalten, dass man definieren kann, welche daten regelmäßig
abgefragt warden.
@Sebastian:
Ich würde mal die NAND Gatter dazwischen packen. Dann hast du einen
sauberen TTL pegel. die USB/RS232 Adapter sind oftmals 3,3V die zwar
auch 5V Vertragen, vielleicht trennt dann der Adapter high/low nicht
sauber. Hast du mal mit einem Multimeter gemessen, du aolltest ca. alle
10 Sekunden sehen, dass die Spannung minimal einbricht. (Nur um sicher
zu sein, dass auch Daten übertragen warden.)
Grüße
Michael
Servus,
Sebastian G. schrieb:> Ohne Ergebniss :-(> Woran kann das liegen???
Das mit dem Multimeter ist ein guter Tipp - die "Normalspannung" sollte
um die 5V liegen, mit Einbrüchen auf ca. 3,x - je nach Geschwindigkeit
des Multimeters.
Prüfe bitte, ob die Parity-Einstellung richtig ist - nicht dass das
Terminal die Daten verwirft sollte die Parity nicht stimmen.
Noch sehr interessant:
Die (sinnvolle) Einsatzgrenze bewegt sich um die -2°C Außentemperatur.
Wie in der Grafik ersichtlich, ist die WP bei niedrigeren Temperaturen
zwar am wärmegenerieren; entzieht jedoch regelmäßig fast genausowie
Wärme zum Frostschutz/Abtauen. Der Heizeinsatz ist komplett aus. Ergo:
Zum "Warmhalten" geeignet, zum Heizen muss bei <-2° der Heizeinsatz an
sein.
Ebenso interessant:
Im Systemhandbuch steht zu "Frostschutz WP", dass diese den Vor und
Rücklauf zur WP bei < 5° beheizt, damit dieser nicht einfriert.
Lustigerweise macht sie das auch, wenn Vor und Rücklauf im Heizbetrieb
mal eben > 20-30° haben!
Grüße
Sascha
Sascha K. schrieb:> Das mit dem Multimeter ist ein guter Tipp - die "Normalspannung" sollte> um die 5V liegen, mit Einbrüchen auf ca. 3,x - je nach Geschwindigkeit> des Multimeters.
So habe jetzt mal gemessen:
Normalspannung CL+ zu CL- 11,68V
Einbrüche auf 10-9,8V
Sebastian G. schrieb:> So habe jetzt mal gemessen:> Normalspannung CL+ zu CL- 11,68V> Einbrüche auf 10-9,8V
Alles super :) Und den Mittelabgriff am RXD anschließen - erstmal was
sehen ist das Ziel.
Kannst du ein kleines Foto deines Aufbaus posten?
Grüße
Sascha
Sascha K. schrieb:> Sebastian G. schrieb:>> So habe jetzt mal gemessen:>> Normalspannung CL+ zu CL- 11,68V>> Einbrüche auf 10-9,8V>> Alles super :) Und den Mittelabgriff am RXD anschließen - erstmal was> sehen ist das Ziel.>> Kannst du ein kleines Foto deines Aufbaus posten?>> Grüße> Sascha
So habe jetzt zwischen Mittelpunkt (MP) des Spannungsteilers
CL+ - 30k - MP - 10k - CL-/GND
und GND gemessen:
Normalspannung: ca. 2,9V
Einbrüche auf ca. 2,5V
Gruß
Sebastian
PS: anbei Fotos von meiner Schaltung
Sebastian G. schrieb:> Normalspannung: ca. 2,9V> Einbrüche auf ca. 2,5V
Ist zu wenig. Falls du hast, nimm bitte eine Kombination aus diesen:
100k / 50k
20k / 10k
2.2k / 1.5k
Damit landest du "im Normalbetrieb" an den 5V - nicht mehr bei < 3V.
Damit sollte es laufen :)
Du kannst auch einen Poti nehmen und am Abgriff auf 5V "im
Normalbetrieb" ausrichten und dann anschließen.
Michael R. schrieb:> Meine Idee wäre das invertieren, CRC> und CSMA/CA im AVR machen zu lassen und das dann z.B. wieder an die IP> Symcon zu hängen.
Tut die Library schon sehr gut. Bin zur Zeit noch am Interfacen
(setRoomTemp...) und dann gibt's die online. Bisher braucht das Ganze
nur:
- Einen Arduino/AVR
- 2 Widerstände (z.B. 100k / 50k)
- z.B. BSP170 n-Kanal FET
- Kabel ;-)
Toll :)
Grüße
Sascha
PS: Der 1284p ist richtig toll mit Arduino!
Sascha K. schrieb:> Sebastian G. schrieb:>> Normalspannung: ca. 2,9V>> Einbrüche auf ca. 2,5V> Ist zu wenig. Falls du hast, nimm bitte eine Kombination aus diesen:> 100k / 50k> 20k / 10k> 2.2k / 1.5k>> Damit landest du "im Normalbetrieb" an den 5V - nicht mehr bei < 3V.> Damit sollte es laufen :)> Du kannst auch einen Poti nehmen und am Abgriff auf 5V "im> Normalbetrieb" ausrichten und dann anschließen.
Habe jetzt ein 10k Trimmer eingebaut und folgendes probiert:
Einstellung 5V RXD gegen GND ohne USB-Converter (Leerlauf)
und
Einstellung 5V RXD gegen GND mit USB-Converter (Belastet)
beides ohne im HTerm Received Data zu bekommen
Einstellung 4800Baud 8Data 1Stop Odd- bzw. Even-Parity
Den USB Converter habe ich getestet in dem ich RXD und TXD verbunden
habe und mal Ascii "Hallo" gesendet habe. Habe "Hallo" zurückbekommen.
Gruß
Sebastian
Sebastian G. schrieb:> Einstellung 5V RXD gegen GND ohne USB-Converter (Leerlauf)> und> Einstellung 5V RXD gegen GND mit USB-Converter (Belastet)
Im Leerlauf sollten da ca 5V anliegen.
Hast du den Inverter dazwischen? Falls ja, häng mal bitte den Abgriff
direkt an RXD.
...das muss doch bei dir auch funktionieren!
Hoffnungsvolle Grüße
Sascha
Sascha K. schrieb:> Sebastian G. schrieb:>> Einstellung 5V RXD gegen GND ohne USB-Converter (Leerlauf)>> und>> Einstellung 5V RXD gegen GND mit USB-Converter (Belastet)>> Im Leerlauf sollten da ca 5V anliegen.> Hast du den Inverter dazwischen? Falls ja, häng mal bitte den Abgriff> direkt an RXD.>> ...das muss doch bei dir auch funktionieren!>> Hoffnungsvolle Grüße> Sascha
Nein habe keinen Inverter dazwischen Mittelpunkt geht direkt auf RXD
Gruß
Sebastian
Hallo zusammen,
ich verfolge den Thread jetzt schon eine Weile, da ich auch eine Brötje
Steuerung habe und die Daten loggen will. Ihr habt ja schon super Arbeit
geleistet und gute Fortschritte gemacht.
Ich habe eine Frage die den Grundaufbau angeht:
Sascha K. schrieb:> - Über ein paar Meter Kabel geht dann der BSB an einen Arduino, der auf> dem Bus mit dem oben beschriebenen Spannungsteiler auf dem BSB lauscht> und die Daten per USB/Seriell an einen Rasperry weitergibt. Auf dem> Raspberry läuft openHAB.
Ist es nicht sogar möglich die digitalen IO-Ports des Rasperry direkt
für die BSB-Busansteuerung zu benutzen? Warum macht ihr den Weg über
USB/Seriell und Arduino?
Außerdem schrieb Sascha K. im Beitrag #2970531:
> - Das BSB-Kabel geht noch weiter und endet an einem QAA75.610. Oben habe> ich mich vertippt fällt mir gerade auf :-/
Ich habe kein externes Bediengerät. Kann ich trotzdem einfach über den
Servicestecker auf den Bus zugreifen? Die Abfragen der Parameter muss
ich dann selber auf den Bus schreiben, um die Mess- und Statuswerte aus
der Steuerung zu bekommen. Ist das soweit richtig?
Hallo Jannik,
Jannik schrieb:> Warum macht ihr den Weg über USB/Seriell und Arduino?
Ich mache den Umweg, um den RasPi zu entlasten und zusätzlich Daten
anzureichern (433MHz Empfänger/Sender, Strom/Wasserzähler, Barometer,
Klingel...). Prinzipiell sollte der RasPi mit seinem UART das
hinbekommen...aber ich lasse die Arbeit lieber einen kleinen uC machen -
das CRC-Checken, Telegramme auspacken und so ist in Summe doch etwas an
Last.
Jannik schrieb:> Ich habe kein externes Bediengerät.
Macht nichts - alles gut. Der Bus kann auch nur aus dem Regler bestehen.
Am Praktischsten ist halt am AVS/Bediengerät des Kessels/etc an den Bus
zu gehen wie oben beschrieben.
Ich habe seit gestern einen zweiten Arduino direkt am AVS hängen, der
alle 30 Sekunden verschiedene Daten abfragt. Der andere Arduino wertet
dann aus ;)
Bei Fragen gerne fragen,
Sascha
PS: Wie ist denn die Arduino-Dichte im Thread? Haben ein paar von euch
einen? Dann würde ich bald endlich mal die Lib online packen. Wenn mich
der Ehrgeiz packt, mixe ich noch RESTduino rein, dass man direkt per IP
Werte abfragen und ändern kann - auch wenn ich den Stromverbrauch des
ETH etwas hoch finde.
@Frank: Du müsstet dann nur noch eine Visu bauen.
Hallo Sascha,
hast du ne idee wo das Problem liegen kann?
Gruß
Sebastian
Sebastian G. schrieb:> Sascha K. schrieb:>> Sebastian G. schrieb:>>> Einstellung 5V RXD gegen GND ohne USB-Converter (Leerlauf)>>> und>>> Einstellung 5V RXD gegen GND mit USB-Converter (Belastet)>>>> Im Leerlauf sollten da ca 5V anliegen.>> Hast du den Inverter dazwischen? Falls ja, häng mal bitte den Abgriff>> direkt an RXD.>>>> ...das muss doch bei dir auch funktionieren!>>>> Hoffnungsvolle Grüße>> Sascha>> Nein habe keinen Inverter dazwischen Mittelpunkt geht direkt auf RXD>> Gruß> Sebastian
Sascha K. schrieb:> PS: Wie ist denn die Arduino-Dichte im Thread? Haben ein paar von euch> einen?
Einige.:-) Sind richtig klasse. Da ich jetzt gelesen habe, dass man in
der Arduino IDE auch C und C++ programmieren kann, werde ich sicher ganz
viel dort machen, wenn ich das mal richtig kann. Atmel Studio ist auf
dem Netbook kein Spaß.
Arduino kann (korrigiert mich, wenn ich falsch liege) keinen ganze Port
auf einmal lesen. Das war bei dem Codeschalter dann doch relativ viel
Aufwand den zu lesen.
Wenn du das in Arduino machen willst, freuen sich sicher alle Anfänger
die so eine Heizung haben. Aber ich denke, wenn man so weit ist die
eigene Heizung auszulesen, dann braucht man nur noch die Arduino
Hardware.
Sodele,
leider habe ich im Moment zu wenig Zeit um hier mehr zu forschen... und
dabei liegt auf dem Seziertisch doch so nettes Equipment danke Numsi und
Helmut.
Anbei die Arduino-Bibliothek in der aktuellen Version, die seit ein paar
Tagen produktiv ist. Besonders die Funktion Query ist toll - sie fragt
den Regler und gibt dann nur die Antwort aus - abgesichert duch einen
Timeout.
Die Funktion Set kann Parameter auf einen Wert setzen. Da leider noch
nicht raus ist, wie die Parameter Nummer in die 4 Hex-Werte umgerechnet
werden kann, ist hier nur beispielhaft für 4 Werte (Modus, Sollwer,
Reduziert, TWW) enthalten um den Speicherbedarf klein zu halten.
@Sebastian: Hast du einen Arduino?
Aufbau ist im Beispiel-Sketch beschrieben.
Grüße
Sascha
Hallo Sascha,
hab meine ersten Versuche auch mit Arduino gemacht und nun lerne ich C.
Dabei bin ich darauf gestoßen, dass die Arduino IDE auch C und C++ kann.
Du musst dann gar nicht mehr auch noch in Arduino programmieren.
Danke für deine Arbeit! Dauert noch etwas, aber dann kann ich es gut
brauchen.
Finde es toll wie ihr das so fleißig gemacht habt und eure tolle
Zusammenarbeit ist beispielhaft.
Sascha K. schrieb:> @Sebastian: Hast du einen Arduino?>> Aufbau ist im Beispiel-Sketch beschrieben.
Nein habe ich nicht, ich möchte das mit einem Embedded IPC abfragen und
verarbeiten der meine gebäudesteuerung übernimmt.
Gruß
Sebastian
PS: Hast du dafür eine Lösung:
Sebastian G. schrieb:
> Sascha K. schrieb:>> Sebastian G. schrieb:>>> Einstellung 5V RXD gegen GND ohne USB-Converter (Leerlauf)>>> und>>> Einstellung 5V RXD gegen GND mit USB-Converter (Belastet)>>>> Im Leerlauf sollten da ca 5V anliegen.>> Hast du den Inverter dazwischen? Falls ja, häng mal bitte den Abgriff>> direkt an RXD.>>>> ...das muss doch bei dir auch funktionieren!>>>> Hoffnungsvolle Grüße>> Sascha>> Nein habe keinen Inverter dazwischen Mittelpunkt geht direkt auf RXD>> Gruß> Sebastian
Hallo zusammen,
ich möchte für den Raspberry Pi
eine Schaltung bauen mit der auf dem BSB
gesendet und empfangen werden kann.
Das Problem: der Raspi hat 3.3V beim GPIO.
Da ich noch Anfänger im Elektronik-Bereich bin,
könnte mir jemand eine Zeichnung/Empfehlung für
eine Schaltung die mit 3.3V beim Sende/Empfangspin
funktioniert zukommen lassen ?
(Habs noch nicht kappiert wie der BSP170 FET
funktoniert und verdratet werden muss..)
2. Frage:
Wird der Bus beim Senden mit dem "BSP170 n-Kanal FET"
eigentlich nun ganz gegen 0 gezogen oder bleibt noch ne Spannung über
und mit wieviel mA ist zu rechnen ?
Möchte die Steuerung nicht zerschiessen ...
Ich hoffe jemand hat zeit mir Anfäger zu helfen,
würde auch sobald der C-Code für den Ras-Pi
steht diesen wieder zur Verfügung stellen.
(Beim programmieren bin ich kein Anfänger ;-)
Gruss
Daniel
Moin moin,
beschäftige mich seit Kurzem auch mit der Kommunikation mit einer Brötje
Gasheizung. Daten mitzuschneiden klappt auch einwandfrei.
Allerdings drängt sich mir die Frage auf, was passiert, wenn im
Telegramm eigentlich eine 0xDC gesendet werden müsste. Was wird dann
stattdessen gesendet? Weiss jemand drüber Bescheid?
Gruss
Max
Hallo Max,
0xDC kann auch im Telegramm vorkommen. Du kannst leider nicht einfach
davon ausgehen, dass 0xDC der Anfang ist. Ich prüfe, ob die Länge ( Byte
4) passt und dann ob die Checksumme Ok ist.
Grüße Michael
Hi,
habt ihr Beispiele für 0xDC in den Daten?
Ich habe seit ca. 6 Monaten den Code oben am Laufen und "vermisse"
nichts. Ich fange bei DC mit einem neuen Telegramm an und prüfe nach
Erhalt Checksumme und Länge. Funzt ;)
Grüße
Sascha
Hallo zusammen,
ist jemand schon weiter beim Decodieren der Messages ?
Vor allem der Sin / Inhalt folgender würde mich interessieren:
SOF : 0xdc
(OK)
SRC : 0x80
(OK) ==> 000 Segment 0 Grundgerät, Regler
RCV : 0x7f
(OK) ==> 127 Broadcast Message
LEN : 0x15
(OK) ==> 21
TYP : 0x02
(OK) ==> 002 Info / Status Update
PARAM : 0x2d000211
(OK) ==> No Menu / HK1 - TBD
DATA : 0x0000247bffffffff0005
(UNKNOWN)
CRC : 0xaf82
(OK)
Bin dabei eine Klasse in Python zu implementieren,
diese braucht zum abhören des bsb weniger als 1% der Rechenleistung des
Raspi.
Für alle die auch direkt an den Raspi wollen,
hier noch der Plan der Schaltung, diese ist getestet und funktioniert.
Um den Sender scharf zu schalten muss der GPIO25 auf Ausgang und 1
konfiguriert werden.
Dies weil der Raspi beim booten den UART und alles andere auf INPUT
setzt und somit der Bus kurzgeschlossen würde,
falls keine Vorsorge getroffen wird.
Weitere Details folgen später oder auf Anfrage ...
Gruss Daniel
Daniel H. schrieb:> Weitere Details folgen später oder auf Anfrage ...>> Gruss Daniel
Hallo Daniel,
ich bin noch lange nicht so weit, dass ich es euch gleich tun könnte,
aber mich interessiert das trotzdem brennend.
Könntest du nicht einen Artikel darüber verfassen und den online
stellen?
Das wäre wahnsinnig nett und hilft dann später sicher vielen mal weiter.
Für die Zukunft ist das auch ein Projekt für mich und ich würde mich
sehr über eure Wegbereitung freuen.
Vielen lieben Dank!
Jungs, jungs, jungs ;)
Anbei meine Lösung, die inzwischen praxis-erprobt ist. Ich verwende
einen arduino mit einem ethernet-shield und ein paar passiven Bauteilen.
Die Werte können z.B. http://heizung/3D050521 abgefragt werden. Die URL
ist dabei die in der oben erfassten Excel-Datei Feld 1-4 zusammen
geschrieben. Die URL hier liefert den Außentemperaturwert.
Die Antwort sieht so {"3D050521":"16.17":"04 0b"} aus. Erstes Feld ist
der abgefragte Parameter, das zweite Feld ist die dezimale
Representation des Rohwertes aus Feld 3.
Über http://heizung/3D650A26/01 kann z.B. der Kühlbetrieb aktiviert
werden.
Außerdem sendet der Arduino Werte die eh gerade über den BSB gehen per
HTTP PUT an meinen openhab-Server.
Grüße
Sascha
Hallo zusammen,
ich habe Saschas Arduino Projekt in ein ethersex module umgeschrieben.
Ist noch nicht ganz fertig und enthält bestimmt noch ein paar bugs aber
ich wollte es trozdem schonmal zur Verfügung stellen. Werte mitlesen
funktioniert bei mir, mit einem AVR-NetIO und der Hardware wie weiter
oben gepostet, einwandfrei.
Anfragen wie das RGT bei Anzeige der Werte im Display kann ich auch
absetzen. Zum senden auf dem Bus verwende ich einen Inverter und einen
BUZ11 n-Fet. Das Setzen von Werten und die Statusupdates habe ich aber
noch nicht raus.
Ich habe das YPort Module als Basis genommen deshalb kann man auf einem
einstellbaren Netzwerkport den BSB Verkehr Transparent mitlesen und auch
aktiv senden. Das ist beim Debugging recht hilfreich.
P.S. Ich Habe das Exelsheet um ein paar Werte erweitert und auch in das
Archiv gepackt.
Gruß
Daniel
Hallo,
habe gerade gesehen das ich vergessen habe die usart init Routine
mitzuliefern.
Damit die Hardware UART mit 8O1 läuft muss man in ethersex/core/usart.h
diese Funktion einfügen:
1
/* init the usart module ( 8O1 )*/
2
#define generate_usart_init_8O1() \
3
static void \
4
usart_init(void) \
5
{\
6
/* The ATmega644 datasheet suggests to clear the global \
Und in ethersex/config.mk (anlegen wenn sie nicht exsistiert) diese
Zeile einfügen:
1
LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm
Ich habe die Werteausgabe über das ecmd-interface nur mit float
hinbekommen deshalb wird das große printf benötigt. Sonst bekommt man
nur ? bei den Werten angezeigt.
Ich habe jetzt einen fork von ethersex auf github erstellt und mein
bsbport modul dorhin gepusht.
Herlunterladen einfach mit:
1
git clone http://github.com/AnDann/ethersex.git
mit make menuconfig das bsbport modul aktivieren. Die restliche
Konfiguration bitte im ethersex Wiki nachschlagen oder Google hilft auch
weiter.
Das Modul lauscht permanent auf Nachrichten die Werte enthalten (Type
Info und Answer). Diese werden in einem Nachrichtenpuffer gespeichert.
Die Puffergröße kann mit make menuconfig angepasst werden.
Diese Nachrichten können mit der ecmd Schnittstelle abgefragt werden.
Gesamten Nachrichtenpuffer ausgeben:
1
bsbport list
Die Spalten sind:
Nachrichtennummer
Adresse in HEX
Wert als Temperatur interpretiert (RAW / 64)
Wert als Festkommazahl mit 1/10 Schritten interpretiert (RAW / 10)
Wert als Festkommazahl mit 1/2 Schritten interpretiert (RAW / 2)
Wert als unsigned Integer
Einzelne Nachricht :
1
bsbport get A1 A2 A3 A4 SRC VALUETYPE
Die Adressbytes sind in Hex im Format 0x00 oder Decimal anzugeben.
SRC ist das die Quelle der Nachricht (normal 0)
Valuetype ist die gewünschte Ausgabeform:
TMP - Wert als Temperatur interpretiert (RAW / 64)
FP1 - Wert als Festkommazahl mit 1/10 Schritten interpretiert (RAW / 10)
FP5 - Wert als Festkommazahl mit 1/2 Schritten interpretiert (RAW / 2)
RAW - Wert als unsigned Integer
Wert Anfragen:
1
bsbport query A1 A2 A3 A4 DEST
DEST ist das Ziel der Nachricht (normal 0)
Wert setzen:
1
bsbport set A1 A2 A3 A4 DEST VALUETYPE VALUE
SRC ist das die Quelle der Nachricht (normal 0)
Valuetype gibt an wie der Wert Value zu verpacken ist:
TMP - Wert als Temperatur interpretiert (VALUE * 64)
FP1 - Wert als Festkommazahl mit 1/10 Schritten interpretiert (VALUE *
10)
FP5 - Wert als Festkommazahl mit 1/2 Schritten interpretiert (VALUE * 2)
RAW - Wert als unsigned Integer
SEL - Speziell zum setzen der Trinkwasserbereitung und der Betriebsart
(VALUE = 0 oder 1 Trinkwasser aus oder an) (VALUE = 0,1,2,3 Betriebsart
Frostschutz,Automatik,Kompfort,Reduziert)
@Daniel H.
Im ersten Byte deiner Nachricht konnte ich die Betriebsart
identifizieren.
DATA : 0x0000247bffffffff0005 <- 0x00 = Frostschutz (ist analog zum
setzen 0,1,2,3)
Wobei sich auch das zweite Byte mit der Betriebsart ändert aber da hab
ich noch keine Idee was das bedeutet.
Es wird kälter, man merkt es --> Bastelzeit --> Klasse
Ich hoffe das das nicht zu abstrakt wird und ich meinen Einstieg noch
finde.
Bin mal gespannt wo das so hinführt...?
Danke an alle!
hi
hab auch eine brötje heizung...
hatte mal irgenwo gelesen das es ein "erweiterungsmodul" fürs netzwerk
gibt....
habe also heute mal wieder gegoogelt und folgendes gefunden...
https://www.broetje.de/Gesamtprospekt_Gas.pdf
scrollt mal auf seite 23...
Zitat:
"Unabhängig regeln.
Einfach mal schnell die Heizung anstellen, wenn es plötzlich kalt wird?
Kein Problem mit der BRÖTJE App! Per Smartphone oder Tablet-PC regeln
Sie die wichtigsten Einstellungen Ihrer BRÖTJE Heizung einfach und
schnell
von jedem Ort aus. Das macht Ihre Heizung noch effizienter und gibt
Ihnen
noch mehr Freiheit in Bezug auf individuellen Heizkomfort"
leider konnte ich diese App nirgends finden...vielleicht jemand von
euch...?
Stefan S. schrieb:> hatte mal irgenwo gelesen das es ein "erweiterungsmodul" fürs netzwerk> gibt....> habe also heute mal wieder gegoogelt und folgendes gefunden...> https://www.broetje.de/Gesamtprospekt_Gas.pdf> scrollt mal auf seite 23...
Das Problem ist, dass die/meine Heizung keine LAN-Schnittstelle
mitbringt. Ergo wie sollen die Daten zur Heizung. Interessant finde ich,
dass von ISR-Plus-Regelung gesprochen wird. Entweder ist es eine "neue
Generation" oder der Regler hat nun analog Novelan eine RJ45 an Board.
> leider konnte ich diese App nirgends finden...vielleicht jemand von> euch...?
Die Bilder sehen wie iDevices aus. Im Playstore konnte ich auch nichts
finden. Vielleicht gibt es die App dann auch per Mail zugesandt (glaub
ich nicht dran...)
Grüße
Sascja
@Stefan S.
Ich glaube die meinen den Zugriff mit der App auf dieses Gateway; damit
hat man dann Netzwerk-Zugriff.
<Zitat>
Der Web-Server OZW672… ermöglicht die Fernbedienung und Fernüber-
wachung von Anlagen über Web.
Der Web-Server OZW672… ist in drei Ausführungen verfügbar: Für den
Anschluss von 1 LPB/BSB-Gerät bzw. von 4 oder 16 LPB-Geräten der
Sortimente Sigmagyr / Albatros und Albatros2.
• Bedienung über Web-Browser mit PC/Laptop und Smartphone
• Bedienung über PC-Tool ACS790
• Verbindungsarten: USB und Ethernet
• 2 Digitaleingänge für Störungsmeldungen
• Anzeigen von Störungsmeldungen im Web-Browser
• Senden von Störungsmeldungen an bis zu 4 E-Mail Empfänger
• Periodisches Senden von Systemreports an die E-Mail Empfänger
• Anlagenvisualisierung im Web-Browser mit benutzerdefinierten
Anlagen-Webseiten
• Verschlüsselung mit https und E-Mail mit TLS
• Trending mit ACS790
• Software-Update
</Zitat>
Auf den Webserver hat Marco bereits hingewiesen:
Autor: Marco L. (marco_l)
Datum: 22.02.2012 17:59
Das Problem an der ferigen Lösung ist der Preis - ich glaube es waren
>300€. Für Business und wo-Geld-egal-ist bestimmt die richtige Lösung,
bei den meisten gerade-erst-ein-Haus-gebaut Leuten bestimmt nicht "aus
Spaß" drin.
Sascha
Darüber habe ich mich auch schon informiert,
einzige Probleme: proprietär (unterstützt keine offenen standards) und
sau teuer >700 CHF
Da mach ich lieber selber was ...
aha...außerdem nicht für Android...
daher nicht gut...kann man nicht mal auf andere (eigene) android geräte
benutzen...
:-(
dann doch eher die eigene Lösung von einigen hier...
Hallo,
vielen Dank für diesen thread, besonders an Sascha! Vor ca. 14 Tagen
wurde ich auf diesen Beitrag aufmerksam. Seit Anfang diesen Jahres
betreiben wir auch einen Brötje 21KW Gaskessel mit der ISR Plus.
Motiviert von euren Beiträgen habe ich kurze Hand ein kleines Gerät
entwickelt, dass die Kommunikation per Ethernet oder COM-Port erlaubt.
Ein paar Eckdaten dazu:
Mikrokontroller:
Renesas RL78G13 (R5F100LJAFA) 64pins, 256K-ROM-Flash, 8K-Data-Flash, 20K
RAM.
IDE: CubeSuite+
http://www.renesas.com/products/mpumcu/rl78/rl78g1x/rl78g13/index.jsp
Ethernet:
Lantronix XPort-Pro mit uCLinux.
mit ser. Port z. B. 115200bd, 8, N, 1.
http://www.lantronix.com/device-networking/embedded-device-servers/xport-pro.html
COM-Port:
z. B. RS232 115200bd, 8, N, 1.
LPB/BSB-Interface:
Eigenentwicklung mit galv. opt. Trennung.
4800 bd, 8, E/O, 1.
Stromversorgung:
Externes Steckernetzteil, DC 5V..35V, < 1W oder vom BSB-Bus Anschluss.
Gehäuse: Bopla Alubos
http://www.bopla.de/de/gehaeusetechnik/product/alubos.html
Im Anhang habe ich ein paar Bilder dazu.
Die techn. Doku werde ich hier nicht online stellen,
wer daran Interesse hat, meldet sich gerne unter sie_hu@gmx.de.
Ein paar Leiterplatten sind noch verfügbar.
Grüsse aus dem Norden von D.
Holger
> Im Anhang habe ich ein paar Bilder dazu.> Die techn. Doku werde ich hier nicht online stellen,> wer daran Interesse hat, meldet sich gerne unter sie_hu@gmx.de.> Ein paar Leiterplatten sind noch verfügbar.>> Grüsse aus dem Norden von D.>> Holger
Hallo Holger,
ist es möglich übers Internet die Heizung einzuschalten, mit deinem
Gerät?
Es geht eigentlich nur um diese eine Funktion.
Wie und wo wird es an die Brötje angeschlossen?
Würdest du ein fertiges Gerät und zu welchem Preis verkaufen?
Hallo foldi,
mein Beitrag soll eine weitere Hardwarelösung zum Anschluss an den
internen Kommunikationsbus der Brötje ISR Plus aufzeigen. Da sich
moderne Hardware wg. der SMD-Bauform kaum noch auf eine
Lochrasterplatine löten lässt, habe ich dazu ein Layout erstellt und
eine Platine herstellen lassen. Diese Hardware erlaubt das Lesen und
Schreiben der am BSB-Bus angeschlossenen Kessel Komponenten über den
localen COM-Port oder von weit entfernten Standorten über den
Ethernet-Port. Zur weiteren Realisierung einer Automatisierungslösung
ist jedoch Software erforderlich, die diese Schnittstellen mit Daten
bedient. Dazu arbeitet Sascha wohl augenblicklich, wie er schreibt, an
einer openhab Lösung (http://www.openhab.org/index.php/start/).
Weiterhin wäre eine Smartphoneapp nötig.
Die Umsetzung des BSB Protokolls auf ein anderes bestehendes Protokoll
mag sinnvoll erscheinen, um auf bereits bestehende Softwarelösungen
aufsetzen zu können. Vieles ist denkbar. Die Hardware benötigt auf jeden
Fall noch weitere Softwarelösungen um erfolgreich funktionieren zu
können. Informatiker sind jetzt hier gefragt, Lösungsmöglichkeiten
aufzuzeigen.
Die Heizung darüber Ein- und Auszuschalten wäre nur ein kleiner
Unterpunkt des ganzen Projektes.
Die Hardware zu verkaufen macht ohne die noch zu realisierende Software
nur Sinn für jmd. der sich eine eigene Softwarelösung erarbeiten will.
lg Holger
Holger, vielen Dank für deine Ausführungen.
Es geht hier in diesem Fall um eine Ferienwohnung, in der, wenn man zum
We dort hin fährt, kurz vorher die Heizung einschalten kann.
Vor einiger Zeit (ist schon fast zwei Jahre her) sah ich mir mal den
Schaltplan an und da (so hab ich das noch im Kopf, aber ich konnte es zu
diesem Zeitpunkt auch nur überfliegen) ist wohl über ein Zusatzmodul von
außen ein Relais zu schalten.
Ein zertifizierter Händler wollte für eine Lösung über GSM richtig viel
Geld dafür haben.
Mittlerweile ist da auch Internet und ich werde mal sehen, ob ich das
nicht mit einem Arduino machen kann, wenn es nur ein Relais ist. Für
Arduino gibt es einfache und gut funktionierende Hardware, auch ne App
für Android ist da und ansonsten über VPN.
Muss mich da wohl doch noch selbst mit auseinander setzen.:-)
Wünschenswert wäre eine komplette (bezahlbare) Lösung gewesen, mit der
neben der Schaltung auch ein Monitoring möglich wäre.
Vielen Dank!
P.S.: Habe mir den Link gerade mal angeschaut. Das ist auf jeden Fall
etwas für mich. Aber dazu muss ich mich erstmal mit den µC und der
Programmierung viel(!) besser auskennen.
foldi, das, was du beschreibst ist das Ziel dieses thread. Die Hardware
existiert soweit, an den Softwarelösungen wird gearbeitet. Saschas
openHAB Lösung mit einem Raspi finde ich erfolgversprechend. Den Weg
dahin sollten wir hier diskutieren, um auch auf unterschiedlichen
Hardwareplattformen zu einem einheitlichen Ergebnis zu kommen.
Evtl. wäre eine Umsetzung des LPB/BSB-Protokolls auf ein anderes
bekannteres Protokoll wie z. B. KNX sinnvoll um die bereits bestehenden
openHAB-Bindings nutzen zu können. Diese Umsetzung kann bereit in der
Interface Hardware von mir (Renesas/Lantronix) oder einer Arduino
Hardware erfolgen.
Bei Allem sollten wir jedoch ein gemeinsames Vorgehen anstreben, um das
Rad nicht 2x zu erfinden :D
Mich würde auch interessieren, ob, und wenn ja, welche bisherigen
Erfahrungen Sascha mit openHAB gemacht hat. Ob z. B. ein eigenes LPB/BSB
binding angestrebt wird oder man besser mit der Umsetzung eines
bestehenden bindings arbeiten sollte.
lg Holger :)
Holger S. schrieb:> Bei Allem sollten wir jedoch ein gemeinsames Vorgehen anstreben,
Das sehe ich auch so, aber ich kann da noch gar nichts zu beitragen, da
die Sache mir noch 3 Nummern zu groß ist.
Ich war schon irre beeindruckt wie die das Protokoll geknackt haben und
konnte dem irgendwann nicht mal mehr folgen.
Den Beitrag, den ich maximal leisten könnte, wären zu grundsätzlichen
logischen Konzepten eine Meinung dazu zu geben. Aber ich fürchte das
setzt wieder die Kenntnisse voraus, die ich noch nicht habe. Deshalb
werde ich mich eher lesend beteiligen.
Diese "open" Geschichten halte ich -nach dem Thread mit dem LNK304-
nicht nur für besonders gut, sondern auch für notwendig.
Man sollte sukzessiv immer mehr Hardware (die nötige Software natürlich
auch), die das tägliche Leben betreffen, in "offene" Hände legen.
Allein schon aus Gründen der Nachhaltigkeit.
Rohstoffe sind nicht unbegrenzt. Beim Kies (den für Beton)kann man das
heute schon sehen. Unternehmer die aus hier umliegenden Kiesgruben Kies
bekommen, müssen hier ansässig sein.
foldi, eine Erweiterung meiner Hardware mit zus. (Halbleiter-) Relais
zum Schalten von 230V Einrichtungen ist eine gut Idee für die Zukunft.
Allerdings bezweifele ich, dass eine kmpl. Abschaltung einer
Heizungsanlage mittels Relais wg. des notwendigen Frostschutzes
erstrebenswert ist :D
Eine Relais Anschaltung mittels openHAB ist auch nicht Bestandteil
dieses threads. Dennoch kann man den Gedanken mit berücksichtigen.
Die 'open' Geschichte ist zwiespältig zu sehen, gibt sie doch
kommerziellen Anbietern häufig eine Steilvorlage für neue Ideen und
deren Umsetzung. Aber dafür gibt es bestimmt andere Foren zum
diskutieren.
lg Holger :)
Hi,
ich würde kein extra Binding für OpenHAB machen. Da es bereits 3
Verschiedene Hardwarevarianten gibt würde es ein Binding sehr
kompliziert machen.
Aus meiner Sicht würde ein Binding nur sinn machen wenn direkt mit einem
Seriellwandler ohne dazwischenliegende Protokollverarbeitung
kommuniziert würde.
Da meine Hardware auf ethersex basiert welches bereits die sehr gut
ausgebaute ecmd Schnittstelle mitbring habe ich auf OpenHAB seite
einfach das http Binding benutzt um auf die ecmd Schnittstelle
zuzugreifen.
Abfrage 1-Wire Temperaturfühler
Das setzen müsste analog zum setzen des Heizungssollwerts funktioniern,
habe ich aber noch nicht getestet.
Was mir noch feht ist eine Erkennung des Fehlermerkers (Glocke im
Broetje Display) damit ich darauf eine E-Mail versenden kann.
Daniel Lindner schrieb:>> ich würde kein extra Binding für OpenHAB machen. Da es bereits 3> Verschiedene Hardwarevarianten gibt würde es ein Binding sehr> kompliziert machen.>
Hi Daniel,
thx für deine Info und Einschätzung, sehe ich ebenso^^
Grüsse
Holger
Leider funktioniert die Wiki : http://www.wikihost.org/w/bsbrev nicht
(mehr). Habt ihr schon eine neue aufgesetzt? Wäre Schade um das ganze
Wissen. Der Thread ist ja echt ellenlang geworden.
Also ich habe eine Schäfer Interdomo Gastherme mit dem Bedienteil
DomoCommand DC 225, das über den Siemens Bus LPB mit der Therme
verbunden ist. Ich habe mal einige Telegramme abgehorcht. Zwischen jedem
Telegramm ist eine Pause von ca 500 ms, so bin ich auf die Länge
gekommen.
(kurzer Ausschnitt)
1
71 7C 00 00 00 00 78 84 07 00
2
74 0A AD FF 1A FE D2 E1 FE 33 00
3
71 1E 00 00 00 00 3D 74 00
4
74 0A B5 01 02 02 04 04 F8 0B 00
5
71 7C 00 00 00 00 78 84 07 00
6
74 0A A5 02 04 04 18 4A 7F DB 00
7
71 1E 00 00 00 00 3D 74 00
8
74 0A AD FF 1A FE D2 E1 FE 33 00
9
71 7C 00 00 00 00 78 84 07 00
10
74 0A B5 01 02 02 04 04 F8 0B 00
11
71 1E 00 00 00 00 3D 74 00
12
74 0A A5 02 04 04 18 4A 7F DB 00
13
71 7C 00 00 00 00 78 84 07 00
14
74 0A AD FF 1A FE D2 E1 FE 66 00
Ich habe noch nicht ganz rausbekommen können, ob 0x71 oder 0x74 der
Master/DC225 ist. Folgendes habe ich aber bereits rausbekommen. Vom 0x71
Gerät werden nur 2 Telegramme versendet:
1
71 7C 00 00 00 00 78 84 07 00
1
71 1E 00 00 00 00 3D 74 00
(2. scheinbar IMMER GLEICH. 1. ändert sich alle paar Minuten)
Das Gerät 0x74 verschickt 3 unterschiedliche Telegramme (denke ich mal)
1
74 0A AD FF 1A FE D2 E1 FE 33 00
2
74 0A B5 01 02 02 04 04 F8 0B 00
3
74 0A A5 02 04 04 18 4A 7F DB 00
0xAD 0xB5 und 0xA5. Die erste Zeile habe ich mal über einen Zeitraum von
mehreren Minuten aufgenommen und mir in Excel anzeigen lassen. Das
Telegramm kommt alle 3 Sekunden.
1
14:15:02 74 0A AD FF EE FE D2 E3 FF 8E 00
2
14:15:05 74 0A AD FF EA FF D2 E3 FF 92 00
3
14:15:08 74 0A AD FF E2 FE D2 E3 FF 9A 00
4
14:15:11 74 0A AD FF DE FE D2 E3 7F CF 00
5
14:15:14 74 0C AD FF DA FF D2 E3 7F D1 00
6
14:15:17 74 0C AD FF D6 FF D2 E3 7F D3 00
7
14:15:20 74 0A AD FF D2 FE D2 E3 7F D5 00
8
14:15:23 74 0A AD FF CE FF D2 E3 7F D7 00
9
14:15:26 74 0A AD FF CA FE D2 E3 7F D9 00
10
14:15:29 74 0A AD FF C6 FE D2 E3 7F DB 00
11
14:15:32 74 0A AD FF BE FE D2 E3 7F DF 00
12
14:15:35 74 0A AD FF BA FF D2 E3 7F E1 00
13
14:15:38 74 0A AD FF B6 FF D2 E3 7F E3 00
14
14:15:41 74 0A AD FF B2 FE D2 E3 FF 65 00
15
14:15:45 74 0A AD FF AE FF D2 E3 FF 67 00
16
14:15:48 74 0A AD FF A6 FE D2 E3 FF 6B 00
17
14:15:51 74 0C AD FF 9E FF D2 E3 FF 6F 00
18
14:15:54 74 0A AD FF 9A FE D2 E3 FF 71 00
19
14:15:57 74 0A AD FF 92 FF D2 E3 FF 75 00
20
14:16:00 74 0A AD FF 8A FF D2 E3 FF 79 00
21
14:16:03 74 0A AD FF 86 FF D2 E3 FF 7B 00
22
14:16:06 74 0A AD FF 7E FE D2 E3 FF 7F 00
23
~
24
14:17:04 74 0A AD FF 6E FF B2 E1 FE 19 00
25
14:17:34 74 0A AD FF 6E FF B2 E1 FE 19 00
26
14:18:02 74 0A AD FF 6E FF B2 E1 FE 99 00
27
14:18:32 74 0A AD FF 6E FF B2 E1 FE 99 00
28
14:19:06 74 0A AD FF 96 FE D2 E1 FE EA 01 00
Sehr merkwürdig das das 2. Byte manchmal zu 0C wird. Das 5. Byte wird
heruntergezählt bleibt bei 14:16:15 bei 0x6E stehen und wird erst am
Ende bei 14:19:06 auf 0x96 angehoben (weil ich die Solltemperatur wieder
auf 21°C stelle?). Die Heizung war während der Zeit aktiv aber es hat
sich an der (19.0°C)Raum-/Kessel(45.0°C)-/(-3.0°C)Außentemperatur nichts
verändert. Ich habe lediglich die Solltemperatur stückweise erhöht und
zwar:
~14:15:00 Soll ist auf 21.0 °C
~14:15:40 Soll auf 21.5 °C gestellt
~14:16:50 Soll auf 22.0 °C gestellt
~14:17:20 Soll auf 22.5 °C gestellt
~14:18:00 Soll auf 23.0 °C gestellt
~14:19:00 Soll auf 21.0 °C zurückgestellt
Ich mache mich heute mal daran, die anderen Telegramme in Excel
darzustellen, mal sehn ...
Ah, nachdem den Thread noch einmal durchgelesen hatte bin ich auf das
Problem mit der Invertierung gestoßen. Zwar nutze ich den richtigen
Konverter, jedoch zeigte mir HTerm ständig Fehler an (alles rot). Da ich
einen FT232RL verwende, kann ich diesen via FT_Prog.exe umprogrammieren.
Dort kann der RX Eingang einfach invertiert werden. Und schwups zeigt
mir HTerm alles richtig an.
Ich habe jetzt fast alles "entschlüsselt". Falls es jemand interessiert:
Am Anfang des Telegramms steht immer 0x17 oder 0x1D. 0x17 steht
für ein Telegramm von der Therme (Ist-Werte) und 0x1D für das RGT DC
225 (Soll-Werte. Das 2. Byte vom RGT steht für die Art des Wertes, der
übermittelt werden soll. 0xOE = Telegramm enthält Solltemperatur für
Heizungsvorlauf. 0x0C = Telegramm enthält Sollboilertemperatur. Bei
den Telegrammen, die von der Therme kommen, ist das 2. Byte immer
0xFD. Das 3. gibt dort an, um was für ein Telegramm es sich handelt
(Es sind alles Ist-Werte). 0x29 = Übermittlung der Außentemperatur.
0x4A = Übermittlung der Brennerleistung, Thermenstatus,
Heizungsvorlauftemperatur. 0x2B = Übermittlung der Boilertemperatur.
Das letzte Byte im Telegramm ist ein CRC Byte. Ich habe es leider noch
nicht herausgefunden, wie es genau funktioniert. Mit Dem Online CRC
Check www.lammertbies.nl/comm/info/crc-calculation.html bekomme ich
nichts logisches heraus :(
RGT Soll-Werttelegramme:
1D 0E FF FF FF FF 0F 00 CA
-> 0x0F00 = 3840 / 64 = 60 °C (Soll Vorlauftemperatur der Heizung)
1D 0C FF FF FF FF 0A 00 D1
-> 0x0A00 = 2560 / 64 = 40 °C (Soll Boilertemperatur, meine Präsenztaste
der Heizung war zur Messzeit auf "AUS" d.h. Heizungstemperatur und
Boilertemperatur werden niedriger gehalten)
Therme Ist-Werttelegramme:
17 FD 4A 00 3B 00 0B 0F 00 64
-> 0x3B = 59 % Brennerleistung
-> 0x000B = wahrscheinlich Status 11 (es gibt noch 7, 19 usw, sicher bin
ich mir da nicht)
-> 0x0F00 = 3840 / 64 = 60 °C Ist-Kesseltemperatur
17 FD 29 FF FF FF FF FF 80 5F
-> 0xFF80 = (2^16) - 65408 = 128 / 64 = -2 °C Außentemperatur in B1
Komplementdarstellung
17 FD 2B FF FF FF FE 0C 80 51
-> 0x0C80 = 3200 / 64 = 50 °C Ist-Boilertemperatur
Ich werde mir nun den "Eletric Imp" holen und die Daten auf einer
Homepage loggen. Die Präsenztaste kann über die Homepage dann geschaltet
werden.
Achja, als Pegelwandler habe ich den sehr einfachen aus dem vorherigen
Beitrag genommen Beitrag "Re: Brötje ISR Plus Kommunikation / LPB" mit
dem BC547 Transistor.
Hallo zusammen,
meine neue Brötje Heizung hat einen Regler LSM14. Der hat einen
USB-Stecker drauf, sowie einen RJ-XY (11?, Telefonsteckerformat), wohl
zu Servicezwecken.
Kann man über einen dieser Stecker die Bus-Telegramme mit einem PI nicht
einfacher auslesen?
Ist in jedem Fall die von Euch beschriebene Hardware-Eigenentwicklung
notwendig? Kann man nicht auch etwas günstiges kaufen? Ich Sachen
Hardware/Elektronik bin ich leider nicht versiert.
Ich habe die Hoffnung, dass Eure Modelle vielleicht etwas älter sind und
diese Anschlüsse noch nicht hatten...
Viele Grüße,
HolyA
Hallo,
welche Funktion die USB Schnittstelle hat ist mir nicht bekannt. Hat
meine ISR SSR nicht.
Wenn sich an dem LPM 14 ein Raumgerät anschließen lässt (Brötje RGT)
würde ich über dessen Anschluss gehen.
Die Hardware eigentwicklung beschränkt sich auf ein paar Bauteile für
die Spannungsanpassung Bus 0-12V auf Microkontroller verträgliche 0-5V.
Leute...fragt mal jemand der was davon versteht,das ist doch alles
Waaahnsinnig komplex und viel zu verwirrend.
Warum fahrt ihr von Hamburg über New York nach Hannover.
Der Trick heißt Siemems WEB Server OZW672. Den an den LPB Bus dran und
dann übers Netzwerk oder USB auf den Rechner....und schon haste alles
über Computer gesteuert-ausgelesen und Trend aufgezeichnet.
Aber bitte nicht in den Fachmann Parametern rumfummeln wenn ma nicht
weiß was man tut.
Toll bei einem Preis von 700€. Mein AVR-NETIO hat gerademal 50€ gekostet
hat ein Display und steuert nebenbei noch einige andere Dinge wie zum
Beispiel das Garagentor.
Genau das ist es. Vor allem macht es ja auch Spaß :). Der Electric Imp
kostet auch soviel und kann viel mehr. Habe nun ne HTML App auf nem
Handy. Kann nun bequem jederzeit die Präsenztaste betätigen und meine
Heizungswerte checken. Letztens habe ich einen neuen Status bekommen:
529 = keine Flamme erkannt. Hat sich jemand mit den Stati der Schäfer
Interdomo beschäftigt?
Das meiste hast du ja schon erkannt.
Hab ein Excelsheet angehängt da stehen einige Werte für P1-P4 drin.
In dem Arduinocode oder im ethersex quellcode stehen auch noch ein paar
informationen zb:
Hi,
kann mir einer von euch vielleicht von seiner Brötje BLW7 die
Einstellungen für das Abtauen geben... ich habe die verstellt ohne
vorher auf zu schreiben und nun taut das Gerät (gefühlt) sehr oft ab.
Im Speziellen brauche ich die Abtauende und Abtropfdauer - also die
Parameter 2951 - 2965.
Ich danke euch recht herzlich und wünsche schonmal einen guten Rutsch :)
- Marcus
Hi all .. all work..
I find problem .. fuck .. in my Delphi component I have set discart null
.. then if received $00 , $00 then delete it .. and this is problem ..
now working .. thanks for all..
regards.
Configuration
HT: ELCO 22H
controller: RVS61.843/160
room temperature controller: QA75.111
photovoltaic plant: 18.9 kWp
Starting from -Daniel H. schema- (to whom I extend my thanks), I
realized a standalone unit with the following features:
HW
microprocessor: PIC32MX350F
protocoll: TCP-UDP <-> PC
RS232/DIRECT <-> controller
SW
language Microchip XC32 + Stack
I expanded the original schema so the input from the controller uses the
RX of the microprocessor and the output is "formed" directly to have a
direct control of the signal.
During the first month of test, I had same chained collisions with the
consequent timeout.
With the delay's time set from 100ms to 3000ms, all goes well.
The unit has the following function:
1- Read a single value;
2- Update a single value;
3- Log all incoming messages;
4- Group command's values, max 15;
Operations of my Home Control(OS:Windows 8):
1- initial set of the 15 group's operating line commands:
900 8400 8404 8406 8820 740 741 8980 8982 1612 1610 8830 8740 8700
N.U.
2- periodically every 10 seconds:
a- the Home Control inquires the interface for the values;
b- normally the interface has the values ready to be sent;
c- the interface reads the 15 values from the controller and waits;
this process takes 2,5 seconds;
if a collision happens,the read process restarts 3 seconds later;
I added new rules to the Home Control:
if the photovoltaic plant is producing more of 10.0 KWh, the upper limit
of the puffer temperature (740-741) is set to 56-58, otherwise to 46-48;
during the night-non-heathing-hours the limit is 36-38;
the same rules for the DHW (1612-1610) with the values of 48-50, 43-45
and 33-35 respectively.
These actions are visible on the attached image.
I have a question to -Daniel Lindner- and -Michael R-.
(I used your tables to build my data base (SqLite))
Q: Have You investigate the following operating line?
2843 I Compressor off time min (paired with 8440)
Normally set to 20 minutes, but I wish to set it to 10 minutes; I don't
have the parameters of the command.
Silvio
Hallo, ich habe das Siemens OCI700 und gehe über die Verbindung LPB.
Ist die hier genannte Software auch für dieses Teil nutzbar unter Linux?
vielen Dank im voraus
Hi to All.
For those who are interested.
SURVEY CODE 2843
-----------------------------------------------------------
Ope. Ope. default
line level Function value Min Max Unit
2843 I Compressor off time min 20 0 120 min
-----------------------------------------------------------
1- I downloaded from the Siemens RVS61.843/160 all the values, about
3000.
Unfortunately there are no links with the line of the manual(!!!).
2- I extracted all the commands with the value 20 (0x14), which was the
active current value.
-----------------------------------------------------------
P1 P2 P3 P4 en value crc
W1 * dc 80 07 0e 07 3d 05 00 00 00 00 14 3d 2f
W2 * dc 80 07 0d 07 3d 05 08 d0 00 14 ad 43
W3 * dc 80 07 0d 07 3d 05 0c 9d 00 14 38 4e
W4 * dc 80 07 0e 07 3d 06 00 00 00 00 14 e5 ad
W5 * dc 80 07 0d 07 3d 06 08 d0 00 14 63 a3
W6 * dc 80 07 0d 07 3d 06 0c 9d 00 14 f6 ae
W7 * dc 80 07 0e 07 3d 07 00 00 00 00 14 5d cc
W8 * dc 80 07 0d 07 3d 07 08 d0 00 14 26 03
W9 * dc 80 07 0d 07 3d 07 0c 9d 00 14 b3 0e
W10 * dc 80 07 0d 07 3d 2d 06 03 01 14 38 a6
W11 * dc 80 07 0d 07 3d 2e 06 03 00 14 c5 77
W12 * dc 80 07 0d 07 3d 2f 06 03 00 14 80 d7
W13 * dc 80 07 0d 07 3d 31 0b 20 00 14 fc e0
W14 * dc 80 07 0d 07 3d 49 0a e0 01 14 d7 4c
W15 * dc 80 07 0d 07 3d 49 0a e2 01 14 b9 2c
W16 * dc 80 07 0d 07 3d 59 04 f2 00 14 71 a0
W17 * dc 80 07 0e 07 3d 59 0b b7 00 00 14 c9 d0
W18 * dc 80 07 0d 07 3d 59 0c e5 00 14 32 90
W19 * dc 80 07 0d 07 3d 65 0b 6f 00 14 bb 49
-----------------------------------------------------------
3- I selected the commands with P2 = 05 and 59 with the value 1 byte
long;
I tried W2, W3 and W16; the last one is the right one.
4- The parameters P1 and P2 are reversed with respect to what used
in this forum.
5- I changed the value from 20 to 10; be careful not to go down
too, even if you can put 0, to allow the compressor
to "rest".
Silvio
Frank W. schrieb:
Weiter oben (im Beitrag #2972295:) schrieb ich.
> Was ich z.Z. absolut faszinierend finde.> Ich mache seit eingen Jahren im Bereich der Yachtelektronik mit> dem SeaTalk Bus rum. Und wie ich mir so Eure Erfolge hier anschaue,> da fällt mir auf dass ich anscheinend meine SeaTalk> Anbindungsschaltung 1:1 verwenden kann und auch einen großen> Teil der Software verwenden kann.
Ich habe nun über den Jahreswechsel endlich Zeit gehabt mal die Hard-
und Software meiner "Segelboot-SeaTalk-Anbinding" an die Brötje Heizung
anzuschliessen und die Software anzupassen. Ich hatte ja den "Verdacht",
dass die Hardwareanbindung zufällig passt und dass die
Kollisionserkennung auch wiederzuverwenden ist. Das scheint in der Tat
so zu sein.
Es gibt noch nicht soo viel. Was aber geht ist.
- Empfangen von Telegrammen und Ausgabe über RS232 / USB in der Form
$STALK,DC,86,00,0E,02,3D,2D,02,15,05*AB<CR><LF>
Das ganze ist also anaolg zu NMEA-0183 Datensätzen aufgebaut, wie sie
z.B. von GPS u.ä verwendet werden. Die Prüfsumme (*AB) am Ende ist noch
aus der alten NMEA Software drin, kann aber ignoriert werden.
- Senden von Telegramm an die Steuerung. Das geschieht auch in der Form
$STALK,DC,80,06..... usw. Prüfsumme muss keine angegeben werden.
Beim Senden erfolgt eine Kollisionserkennung, so dass das Senden auf den
Bus sicher ist und keinen anderen Teilnehmer stört.
Das bedeutet, die einfache Hardwareanbinding funktioniert fast ohne
Änderung. Nur R1 musste weggelassen werden.
( siehe
http://www.gadgetpool.de/nuke/modules.php?name=News&file=article&sid=20
)
Im Moment habe ich das ganze auf eine ATMega1284p laufen.
Sollte es jemanden interessieren - einfach melden.
Jetzt geht's dran die Daten aus den Telegrammen zu extrahieren. Die
tollen Info's hier erleichtern das schon erheblich. Danke hierfür !
Hi to All.
For those who are interested.
SURVEY CODE 2842
-----------------------------------------------------------
Ope. Ope. default
line level Function value Min Max Unit
2842 I Compressor run time min 10 0 120 min
-----------------------------------------------------------
X6 * dc 80 07 0d 07 3d 59 04 f1 00 0a db 0f
1- Changed the value from 10 (0x0a) to 8.
2- The overshoots, more then 2C° over the command "741" value,
are reduced with a smooth flow temperature.
3- the ON-OFF cycles are increased from 2 to 3 per hour,
safe enough not to damage the compressor (again be careful).
Silvio
I want to share the good functioning of the Photovoltaic and ThermoPump
systems.
Attached two snapshots of the graphs of the day 01/25/2015 with sun and
scattered clouds.
1- PW graph shows the production, in green, of the photovoltaic system
with reference to the theoretical production, in yellow.
2- HT graph describes the activity of the heatpump.
horizontal lines, in fuchsia, are the setting of the value 740" and
"741";
horizontal lines, in cyan, are the setting of the values "1610" and
"1612".
3- As can be seen, when the production of energy exceeds 10 kWh,
for at least 3 minutes, the settings are raised;
if it falls below this level, again for 3 minutes, the settings are
lowered.
4- The heat demand ends at 10:40;
resumes at 12:30; the temperature has a steep descent, sensor B4,
rises again at 12:41, but stops at 12:46.
5- The heat demand ends at 13:30.
6- From 13:30 onwards there is an accumulation of heat power.
7- the shortest length of Hp-ON, in blue, is 8 minutes, the new setting
of "2842".
8- the shortest distance of Hp-ON, in blue, is 10 minutes, the new
setting
of "2843".
I am very Happy.
Silvio.
http://www.bing.com/maps/
46.006120
12.704750
the view is dated 2012.
Hi Silvio,
thanks for your investigations and congrats to your success :)
Just FYI:
2842 Compressor min runtime is parameter 3d 59 04 f1
2843 Compressor min stand-still is parameter 3d 59 04 f2
Sascha
Hallo zusammen,
echt toll, was Ihr erreicht habt! Vielen Dank!
Ich würde gerne die Präsenztaste des RGT simulieren. Ich wäre Euch echt
dankbar, wenn jemand (Sascha ;-) ) die Daten für das Umschalten mittels
Präsenztaste am RGT zwischen Komfortsollwert-Heizbetrieb und
Reduziertsollwert-Heizbetrieb loggen könnte.
Lieben Dank und Grüße,
Philipp
To Mr. Philipp S.
I suppose that You are referencing to:
730 E Summer/winter heating limit
In my room controller QA75.111 (ISR-RGT), the command is part of the
"Heating circuit 1" menu, with the default value of 20° C.
The value applies only if the:
900 F Optg mode changeover
None ¦ Protection ¦ Reduced ¦ Comfort ¦ Automatic
is set on ¦Automatic¦; the command is the last line of the same menu.
Silvio
Hallo,
angeregt durch eure tolle Arbeit, habe ich inzwischen einen Webserver
für das Monitoring und die Steuerung meiner ELCO Heizung auf Basis eines
mega2560 mit Ethernetshield realisiert.
Die aktuelle Software, den Adapter-Schaltplan und weitere Infos findet
ihr hier:
http://forum.fhem.de/index.php/topic,29762.msg255623.html#msg255623
Gruß,
Gero
Dear Silvio,
many thanks for your quick reply! Unfortunately, it did not exactly
answer my question.
According to the installation manual of the Brötje heating, the
"Präsenztaste" on the room controller (RGT) enables you to switch
between "Reduced" and "Comfort" mode. However, with the important
difference that the selection will not be permanent, i.e., it will be
set back by the program on the next programmed change. Hence, for
example, if one goes early to bed (or leaves home), one can switch to
"Reduced" mode to save energy. Nevertheless, in the morning, for
example, the program will switch automatically back to "Comfort" mode.
This function is, as far as I know, only available at the RGT.
I want to simulate the "Präsenztaste" to be able, for example, to turn
the heating to "Comfort" mode using a web interface. To this end, I
would need a dump of the command on the BSB bus. Since I do not own an
RGT, I would be very grateful if someone could provide such a dump.
Hence, I would need a BSB bus dump (the hexadecimal prints above in this
thread) when the "Präsenztaste" is pressed twice, i.e., changing between
"Comfort" mode and "Reduced" mode, and back.
I hope my explanations are clear.
Cheers and many thanks!
Philipp
To: Philipp
If I understand your need:
Operation mode change.
The following command changes the operating mode:
-----------------------------------------------------------
Ope. Ope. default
line level Function value
900 F Optg mode changeover
None ¦ Protection ¦ Reduced ¦ Comfort ¦ Automatic
¦ Protection ¦
-----------------------------------------------------------
command: 3d0507be
values:
VALUE CRC
EN.
dc 80 07 0d 07 3d 05 07 be 00 01 bb 53 Protection
dc 80 07 0d 07 3d 05 07 be 00 02 8b 30 Reduced
dc 80 07 0d 07 3d 05 07 be 00 03 9b 11 Comfort
dc 80 07 0d 07 3d 05 07 be 00 04 eb f6 Automatic
(my controller is RVS61.843/160)
Silvio
Hallo Sascha,
bin schon länger mit großem Interesse an diesem Thread am lesen... Habe
auch das Modul zum lesen/schreiben nachgebaut und getestet.
Lesen geht ohne Problem nur das Schreiben will irgendwie nicht..
Kannst Du mir vielleicht noch,als erklären wie man das machen kann?
Insbesondere mit dem Kollissions ...?
Oder wie mache ich das z.B. mit einem Terminalprogramm?
Vielen Danke
Gruss
Michael
Hello all,
I'm interested in this project but trying to translate from German I
did'n understand very well how to start with tests on my home system.
To start I'd like to understand:
1- Which is the final layout of circuit to connect LPB bus to Arduino or
to a USB-serial(TTL) converter?
2- Is there a basic Arduino project to use as working base project?
Thanks and regards
Mauro De Vecchi
Hi Mauro,
You can use the diagram i posted on 9.1.2013, regarding arduino check
the post from Sacha on 26.1.2013 (BSB.rar)
I also posted on 5.1.2013 a spreadsheet with parameters that might help
to identify messages on the bus depending on the system you try to
access.
Best regards
Michael
Hello all,
I would like to ask if anyone of you know parameters related to the heat
pump and could share them with me. There are none in the
ISR_Parameter1.xlsx published here.
I tried to read communication on BSB bus, but I only see broadcasts from
control unit (RVS61.843).
I suppose it's because the wireless connection of room unit (QAA78.610
and AVS71.390) which is not mirrored to BSB bus.
Best regards
Richard
Guten morgen
Draussen liegt der erste Schnee und ich habe einigen Output zu
verkünden.
Zuallererst möchte ich allen Beteiligten insbesondere Kuscheganxta
,anndann , mitternachtsdiver und niob danken.
Ihre Erkenntisse haben mir als Hobbybastler sehr geholfen.
Ich habe mich diesen Herbst entschlossen, meine neue Heizung zwecks
datenauswertung und optimierung zu überwachen.
Ich habe diesen inzwischen sehr langen Thread gelesen, etwas
zusammengefasst, eine kleine Schaltung erstellt, ein Platinchen in China
bestellt, etwas C++ zusammenkopiert, ein Excel erstellt und einige
weitere Quellen im Internet bemüht.
Gerne würde ich eure Meinung und insbesondere Verbesserungsvorschläge
entgegennehmen.
Das Modul basiert auf dem ESP8266, welcher auch mit der Arduino IDE
programiert werden kann und nebenbei Wifi eingebaut hat.
Die Daten werden auf eine MicroSD Karte geloggt. Seit zwei Wochen ist
der Prototyp an einer Thysion S mit einer Siemens LMU7 am bsb Bus aktiv
und speichert minütlich KesselTemp/Vorlauf/Rücklauf und
Aussentemperatur.
Bei der Schaltung würde ich gerne noch einen Verpolungsschutz und
Entstörung einbauen. Bei der Spannungsversorgung bin ich mir bezüglich
Verlustleistung und Stabilität nicht ganz sicher (peak ~200mA).
Hat eine Elektronikprofi Lust und Zeit ?
Die Korrelation der bsb Commands (A1..A4) mit einer
Bedienzeilennummer(BZ) habe ich mit einem C# progi erstellt, welches via
Serial das Telegramm zur aktuellen gewählten Bedienzeile empfängt und
nach der entsprechenden BZ fragt. Beim AVS37 Display sind einige
Menüpunkte mit zwei Werten ausgestattet, und generieren auch
entsprechend Requests/Answer Telegramme auf dem Bus und sind in der
Datei bsbcmd.txt mit "-2" erkennbar.
So kann man bequem im Fachmannmodus jede Einstellung an der Heizung
anwählen und am Notebook die entsprechende BZ eingeben.
In diesem Zusammenhang bin auch das Dokument LMU-2.08-3.0-p7494_1e.pdf
von Siemens gestossen, welches einige Parameter sehr detailiert erklärt.
Leider behandelt es nicht alle Parameter, da es sich auf die ältere
LMU64 bezieht.
Hat jemand ein solches Dok in Deutsch für die LMU7 ?
Weitere Meilensteine:
Ich werde in den nächsten Tagen/Wochen einigen Code auf Github
platzieren und eine v0.2 der Platine erstellen.
Auch wird Wifi/mqtt ein Thema sein.
Die wichtigsten Fakten zum Bus findet Ihr unter
http://steini.net/wp/?p=139 und zur Platine http://steini.net/wp/?p=192
gruss aus der verschneiten Schweiz
Hallo zusammen,
dank der Infos aus diesem Thread betreibe ich seit geraumer Zeit einen
kleinen Raspberry-Pi-Datenlogger an meiner Broetje ISR Plus. Als kleines
Dankeschön habe ich über Weihnachten den Code mal etwas aufpoliert und
in Github platziert:
https://github.com/loehnertj/bsbgateway
Es gibt ein Kommandozeilen-und ein Webinterface. Weiterhin kann man
Werte über lange Zeit aufzeichnen und primitive Trigger einrichten (z.B.
Email wenns draußen <0°C wird).
Das ganze ist in Python geschrieben und zumindest auf dem Raspberry in
kürzester Zeit zum Laufen zu bringen.
Es ist theoretisch möglich weitere Geräte mit anderen Feldern anzulegen.
Im Moment gibt es nur die ISR-Plus, wobei die Feldliste keineswegs
vollständig ist. Ich arbeite auch noch daran sämtliche Datentypen zu
verstehen.
Falls es jemandem weiterhilft würd ich mich sehr freuen :-)
Viele Grüße,
Johannes
Ich versuche immernoch meine Telegramme komplett zu entschlüsseln. Ich
habe nämlich einen anderen Aufbau wie ihr da ich eine Schäfer Therme
habe mit dem Raumregelgerät DomoCommand DC225. Hat jemand so ne Kiste
und hat sie entschlüsselt?
Hier meine bisherigen Erkenntnisse:
Beitrag "Re: Brötje ISR Plus Kommunikation / LPB"
Hallo,
man muß unterscheiden, ob es der
LPB Bus oder der
BSB Bus oder der
Bus zum DC225.
Das sind schon Unterschiede :-)
wenn auch gewisse Ähnlichkeiten vorhanden sind.
Viel Erfolg weiterhin
Bei mir ist es nur der Bus von der Therme zur DC225 (2 Draht). Da fehlen
mir immer noch Infos bzgl. der 2 Bytes, die wohl einen Status oder so
abbilden. Am Ende eines jeden Telegrams habe ich auch nur 1 Byte CRC.
Hallo,
DC225 ist über den "PPS Interface" Bus angeschlossen und nicht über den
LPB oder über den BSB Bus.
Und das sind alles andere Protokolle.
PPS = Punkt (zu) Punkt Schnittstelle laut Siemens.
Leider wird es all zu gern alles vermischt hier.
Viel Erfolg und viele Grüße
Guten Tag!
1. Oben hat schon ein Schreiber die Frage gestellt, was aus dem Wiki
geworden ist. Ist das nun endgültig in der Versenkung verschwunden?
2. Ebenfalls ist hier mehrfach die Frage gestellt worden, wie die
Sendeelektronik des LPB-Bus-Interfaces mit Spannung versorgt werden
soll. Ich hatte mir einen Design wie folgt überlegt, auch inspiriert
durch die galvanisch getrennte Schaltung mit Optokopplern aus diesem
Forum. Das Ergebnis ist, kurz gefasst: für die LPB-Bus-Sendeseite kann
ein DC-DC-Wandler die Stromversorgung übernehmen. Hier die Langversion
der Beschreibung:
Die Verbindung zum PC geht über USB mit einem FTDI Schnittstellenwandler
USB <=> seriell. Die Platinchen gibt es fertig, sie sind in der Lage,
außer der Signalwandlung nebenbei auch 5V mit max 500mA (siehe USB
Spezifikation) für das gesamte Interface zu liefern. Damit ist die Frage
der Stromversorgung für das LPB-Bus Interface insgesamt beantwortet. Das
OCI700 Service Tool wird ja auch über ein USB-Kabel mit dem PC verbunden
und braucht keine externe Stromversorgung.
Der FTDI-Wandler liefert serielle Empfangs- und Sendedaten mit
TTL-Level. Serielle Empfangsdaten vom LPB-Bus gehen zum PC, serielle
Sendedaten vom PC gehen zum LPB-Bus. Mit einem Pegelwandler TTL <==>
RS232 könnte man diese beiden Datenströme abgreifen und an einem
zusätzlichen seriellen Interface mitschneiden (oder gleich ein solches
serielles Interface als Datenverbindung zum PC benutzen).
Ich denke an einen Ausbau der PC-Seite mit einem Arduino, der schon
Empfangsdaten vorverarbeitet, bevor der PC sie zu sehen bekommt und der
beim Senden CRCs einfügt und auf Kollisionen prüft.
===========
Optokoppler für Daten vom und zum LPB-Bus zwischen der PC-seitigen
Elektronik und dem LPB-Bus-Interface trennen die Heizung galvanisch vom
PC.
Die Stromversorgung des LPB-Bus-Interface ist ueber einen DC-DC-Wandler
(ca. 3 Euro) ebenfalls galvanisch getrennt. Der Preis geht im Rauschen
des Projekts unter).
Diese Trennung lässt mich, was die Heizung angeht, ruhig schlafen. Ein
abgerauchter PC wäre einfacher zu ersetzen :-)
===========
Das LPB-Bus Interface sieht aus, wie schon im Forum beschrieben:
empfangsseitig ein Spannungsteiler und (Darlington-)Transistor als
Eingang, der Transistor treibt die LED in einem Optokoppler LPB-Bus ==>
PV. Der Ausgang eines zweiten Optokopplers PC ==> LPB-Bus treibt einen
MOSFET als Sende-Schalter. Es gibt Optokoppler mit integriertem CMOS/TTL
Treiber (hp 5082-4360, 6N137, HCPL2630 (dual), PC900V, usw.), welche die
Schaltung auf beiden Seiten vereinfachen helfen. Deren aktive
Ausgangsstufen benötigen aber eine Betriebsspannung; ohne einen
DC-DC-Wandler für diese Spannungsversorgung funktioniert das nicht.
Verschiedene Schreiber haben sehr viel Vorarbeit geleistet. Ich habe
mir die Liste der LPB-Telegramme angesehen und durch die sog. "ProgNr",
wie es bei Brötje heißt, ergänzt (siehe Anhang) und noch viele weitere
bisher nicht dokumentierte Parameter eingefügt. Natürlich haben manche
Betreiber eine andere Anlage (z.B. mit Wärmepumpe) und somit zusätzliche
Parameter, zu denen nur sie Unterlagen haben (haben sie?). Wäre es nicht
gut, wenn die angefangene Datei allmählich in Zusammenarbeit
vervollständigt würde?
Hat jemand auch den Datenteil der Telegramme dokumentiert, wie die
jeweiligen Parameter definiert und gesendet bzw. dekodiert werden?
====
Die Brötje-Steuerungen können durch ein Fernwartungs-Interface erweitert
werden. Aus der Ferne wählt man sich über einen Modem ein, vor Ort hat
man die Möglichkeit, statt des Modems einen PC mit einem seriellen
Interface per Kabel anzuschließen. Ein SIEMENS-Programm im PC gestattet
in beiden Fällen, die Parameter der diversen Menüs auszulesen,
darzustellen und zu ändern. Der Benutzer muss sich AUCH VOR ORT in
seiner Funktion und mit einem Zugangscode identifizieren, um Zugang zur
Anlage über das Fernwartungsinterface zu erhalten.
Dasselbe PC-Programm arbeitet auch mit dem OCI700 Service Tool zusammen,
das direkt an den LP-Bus angeschlossen wird, und stellt im Prinzip die
gleichen Daten dar. Ein Unterschied zum Fernwartungsinterface ist, dass
dabei keine Code-Abfrage (Passwort) erfolgt.
Da die hier erwähnten Selbstbau-Interfaces ebenfalls direkt an den
LP-Bus angeschlossen werden und bekanntlich als Sniffer benutzt werden
können, könnte man das OCI700 LP-Bus-Kabel über ein solches
Selbstbau-Interface schleifen. Man sieht dann an dessen RS232-Interface
jedes Byte, das über den LP-Bus geht, egal, ob passiv von den
Heizungsgeräten im Normalbetrieb ausgetauscht oder aktiv vom/zum OCI700
veranlasst.
Ob die Daten des OCI700 denen ähneln, die hier schon bekannt sind,
müsste man feststellen.
Ahoi bsbfreaks
Der Korrelation der BSB CMDS [Byte 6-10] mit den Bedienzeilennummern
(BZ) der verschiedenen Herstellern ist in der Tat ein guter Ansatz. Auch
wäre da noch einige Attribute mehr zu berücksichtigen wie DatenTyp, Max,
Min, defaultwerte, Sprache(Text der BZ) und eventuelle Abhängigkeiten zu
anderen BZ's.
Die Korrelation habe ich mit einem progi gemacht, welches in realtime in
der CMDdb nachschaut ob die BZ vorhanden ist, wenn ich an der avs37 das
Rad drehe und wenn nötig die BZ abfragt. Das Resultat ist oben in der
cmdbz.txt zu finden. Im Prinzip kann mann mit diesem Approach auch
andere aktive Komponenten wie das OCI700 "abhören", aber das ist mir zu
teuer und die für mich relevanten Telegramme habe ich gefunden.
Ich habe meine nicht kompletten Erkenntnisse in dieser Tabelle
platziert.
https://ethercalc.org/kex95kekhj [Elco mit SiemensLMU w07]
Eventuell ist ethercalc ein aproach zur zusammenarbeit da ich gerade
kein OpenOffice am laufen habe
gruss aus der schweiz
[quote="Rolf.S"]Eventuell ist ethercalc ein approach zur zusammenarbeit
..[/quote]
Einerseits leuchtet mir der Vorschlag ein, wenn mehrere an einer
Dokumentation arbeiten. Nur: Auf der Seite von Ethercalc steht "Drop a
.csv, .ods, or a .xlsx file here to import it". Wie man jedoch das
Rechenblatt wieder heraus und auf den eigenen PC bekommt, das konnte ich
auf die Schnelle nicht herausfinden. Wahrscheinlich bietet Ethercalc
diese Möglichkeit bewusst nicht.
In Ihre Tabelle habe ich reingeschaut und stelle fest, dass es wieder
von einem Forumsschreiber eine Menge Neues zu lernen gibt. Danke fürs
Teilen!
@Rolf.S: Wie Sie "am Rad drehen" und dabei noch automatisch ein Programm
füttern, ist mir nicht klar. Können Sie ein wenig dazu schreiben?
1. Was ist die CMDdb, wo ist sie, woher kommt sie, wie greifen Sie
darauf zu?
2. BZ = Bedienzentrale ?
Ich bitte um Nachsicht, dass ich die Abkürzungen nicht alle kenne.
Was Ihren Hinweis auf Standard- oder Werkswerte der Parameter angeht: in
der Tabelle, die ich ergänzt habe, stehen jetzt auch viele dieser
Angaben. Standard- oder Werkswerte sind in Fettdruck hervorgehoben.
Erfolgsmeldung: Mein Eigenbau-Interface funktioniert lesend und - noch
ohne CSMA/CA, das wird der nächste Schritt - schreibend. Was ich vom PC
über eine serielle Leitung an das Interface sende, wird auf den Bus
geschrieben und unmittelbar vom Empfangsteil, das am Bus hört, über die
serielle Leitung wieder an den PC zurückgegeben. Die Heizungssteuerung
und einen LB-Bus brauche ich zu diesem Test nicht, nur ein 12V-Netzteil
und einen Pull-up Widerstand an der Bus-Datenleitung :-)
Als nächstes kommt die von Sascha auf dem Arduino programmierte
Kollisionsvermeidung zum Einsatz. Eigentlich sollte dafür ein Arduino
micro ausreichen. "We'll see, said the blind man as he picked up the
hammer and saw."
Bei der Portierung der BSB.rar Software (siehe oben) auf einen Arduino
micro habe ich folgendes festgestellt:
1. Man muss beachten, dass der Arduino micro nicht die selben Rx/Tx Pins
für das Software UART verwenden kann wie der Arduino Uno, für den Sascha
sein Programm geschrieben hat.
"Not all pins on the Leonardo and Micro support change interrupts,
so only the following can be used for RX: 8, 9, 10, 11, 14 (MISO),
15 (SCK), 16 (MOSI)."
Ändern der Instantiierung in BSB_Demo.ino
// Arduino Uno:
// RX Pin 5, TX Pin 4
//BSB bus(5,4);
// Arduino micro:
// Rx Pin 8, Tx Pin 9 (beispielsweise)
BSB bus(8,9);
2. In Zeile 172 in bsb.cpp habe ich den Zähler der for-Schleife
sicherheitshalber auf null initialisiert: for (byte i=0; i < LEN; i++)
3. Sascha verwendet eine modifizierte SoftwareSerial library, um eine
Methode aufrufen zu können, die in der Arduino SoftwareSerial-library
'private' wäre. In seiner modifizierten SoftwareSerial library ist in
der include-Datei SoftwareSerial.h die Methode uint8_t rx_pin_read() bei
den 'public' Methoden statt bei den 'private' Methoden aufgeführt.
Sollte der Compiler diesen Fehler melden, hat man die Standard-Arduino
library erwischt.
Ob die SoftwareSerial library die Daten invers oder in Standardlage
verarbeiten soll, könnte man im Konstruktor über einen dritten boolschen
Parameter bestimmen.
Hallo Harald,
> Wäre es nicht> gut, wenn die angefangene Datei allmählich in Zusammenarbeit> vervollständigt würde?
Ein zentrales Verzeichnis wäre durchaus sehr gut. Die .ods-Datei kann
man nehmen, m.M.n. wäre ein besser maschinenlesbares Format (NICHT .xml
:-)) besser.
Du kannst Dich gern bei mir bedienen:
https://github.com/loehnertj/bsbgateway/blob/master/bsbgateway/bsb/broetje_isr_plus.py
(sollte auch für Nichtprogrammierer lesbar sein) - oder ich konvertiere
die Daten mal in .csv.
Um nützlich zu sein müsste die .ods-Datei aber noch deutlich mehr Infos
zu jedem Feld enthalten:
-Datentyp;
-Divisor (für int16-Feld)
-schreibbar ja/nein;
-Nullwert erlaubt ja/nein;
-Minimalwert, Maximalwert, Einheit;
-Choice-Felder: numerischer und Textwert für jede Auswahl.
Ich meine mich auch zu erinnern dass die Zuordnung Cmd zu Prognr bei
meiner Anlage teilweise von der .ods abweichend war. Habe es mir leider
nicht aufgeschrieben wo das der Fall war.
Meine Vorgehensweise ist übrigens: Am Bedienpanel die Felder
durchdrehen; die Telegramme hintereinanderweg mitsniffen; dazu jeweils
die o.g. Infos in "Steno" aufschreiben. Dann mach ich hinterher bequem
am Rechner alles "schön". (Hab auch noch Arbeitsvorrat :))
> Hat jemand auch den Datenteil der Telegramme dokumentiert, wie die> jeweiligen Parameter definiert und gesendet bzw. dekodiert werden?
Ja, siehe hier:
https://github.com/loehnertj/bsbgateway/blob/master/doc/protocol.md
Betr. Hardware (CSMA): Ich habe in meiner Schaltung einen Monoflop an
die CTS-Leitung des RS232 angeschlossen, der für eine kurze Zeit das
Senden sperrt, wenn er Traffic sieht. Damit kann man (theoretisch) die
Kollisionsvermeidung komplett in Hardware machen.
Was das Format einer Dokumentation angeht, habe ich keine Präferenz. Mit
XML hatte ich mal ein paar Parameter versuchsweise angefangen zu
dokumentieren, bin aber, als ich bei komplexeren Situationen den Umfang
abgeschätzt habe, davon abgekommen. Wenn es jemand durchzieht, OK. Wenn
eine XML-konforme(!) Dokumentation vorliegt, gibt es dafür wenigstens
fertige Parser-Bibliotheken. Nötig? Ich glaube nicht.
Dass die Hersteller nicht die selben Parameter, Parameternamen und
denselben laufenden Parameterindex (ProgNr) vergeben, kommt mir nicht
abwegig vor. NIH (Not Invented Here).
Ihre Gedanken, welche Angaben außerdem noch nützlich wären, teile ich
auf jeden Fall. Evtl. ist mit dem Vermerk "Nullwert erlaubt" gemeint
"Parameter mit seinen gespeicherten Daten kann deaktiviert bzw.
aktiviert werden". Beispiel sind die Ferienprogramme. Wenn nicht, wäre
dieser Sonderfall der (De-)Aktivierung ein weiteres
Konfigurationsdetail, das sich im Telegramm wiederfindet und das
dokumentiert werden sollte.
Mit GitHub habe ich gedanklich gespielt. Je länger ich überlege, desto
mehr komme ich zur Überzeugung, dass speziell mir eine Datei nur im
Internet nichts nützt. Ich muss nicht nur am Schreibtisch mit
Internetanschluss, sondern auch an der Anlage darauf zugreifen können,
und da ist ein Schlepptop, auf dem sich die Dokumentationsdateien
befinden, IMHO die bessere Lösung.
oha
es hat schnee draussen und aktivität hier :-).
@Harald
Maschinenlesbar wäre wirklich flott. Dann wäre eine portierung auf C
etwas einfacher.
Es gibt bei mir einige BZ (ELCO-avs37) mit zwei Anzeigewerte, diese habe
ich in der EtherCalc Tabelle mit einem -2 postfix versehen.
Die protocol.md ist herrvorragend.
Es gibt noch das Telegram type=8 [ERROR] und entsteht wenn z.B ein
illegales cmd (Field ID) abgesetzt wurde try 063D0D0518.
@brha
EtherCalc
hat in der tabelle oben links so einen pfeil nach unten -> Export in
html|csv|Excel.
cmddb.txt
Ich hab mir ein C# Progi zusamengestiefelt, damit ich bei der
Korrelation CMD und BZ keine Fehler mache (steno liegt mir nicht) .
Die Anbindung erfolgte seriell an den bsblink und prüfte, ob zum cmd
eine BZ vorhanden ist, ansonsten erscheint eine Inputbox für die Eingabe
der unbekannten BZ. Das ganze war ein "Quick and Dirty" Aufbau.
Die entstandene Datei war im Post
Beitrag "Re: Brötje ISR Plus Kommunikation / LPB".
Siemens LMU's
Grundsätzlich werkelt beim BSB immer eine Siemens Steuerung, welche von
OEM "individualisiert werden kann.Im Kapitel 12 @
LMU-2.08-3.0-p7494_1e.pdf findet man zwei weitere nummernspalten und
eine TextSpalte (z,b pH2Omin) und die entsprechenden Berechtigunslevels.
Leider führt dieser Weg der Datenaquise nicht wirklich zum Ziel, wenn
man nur einige "nützliche" Werte auslesen möchte. Siemens könnte sich
viel Reputation holen, wenns Sie etwas auf Transparenz setzten würden.
SoftwareSerial:
Diese Erfahrungen habe ich auch gemacht. Ich würde gerne auf HW Serial
wechseln (robuster und Parity ist dabei), aber leider hat der ESP8266
(mein aktueller favorit) dazu zuwenige pins.
Testing mit bsbsimu
Damit ich den Aufbau Testen konnte habe ich mit einem Logicanalyser eine
Aufzeichnung des bsb Signals der Heizung gemacht, die Daten konvertiert
und auf einen UNO geladen und diesen an mein bsblink angeschlossen. So
kann ich jederzeit offline testen. http://steini.net/wp/?p=250
Github
kann man herunterladen dann sind die Daten lokal verfügbar.
git ist eine Versionsverwaltung erlaubt nahezualles -> sofern man zeit
hat sich einzuarbeiten.
Glossar
BZ= BedienZeile
cmd = Telegramm byte 6->10
bsblink = meine HW implementation - esp8266 basierend
Hallo zusammen,
> Was das Format einer Dokumentation angeht, habe ich keine Präferenz. Mit> XML hatte ich mal ein paar Parameter versuchsweise angefangen zu> dokumentieren, bin aber, als ich bei komplexeren Situationen den Umfang> abgeschätzt habe, davon abgekommen.
Hatte doch geschrieben NICHT .xml - ich finde .xml-Dateien grausig zu
lesen. Mir persönlich reicht auch klar lesbarer Programmquelltext als
Doku. ;-)
> Ihre Gedanken, welche Angaben außerdem noch nützlich wären, teile ich> auf jeden Fall. Evtl. ist mit dem Vermerk "Nullwert erlaubt" gemeint> "Parameter mit seinen gespeicherten Daten kann deaktiviert bzw.> aktiviert werden". Beispiel sind die Ferienprogramme. Wenn nicht, wäre> dieser Sonderfall der (De-)Aktivierung ein weiteres> Konfigurationsdetail, das sich im Telegramm wiederfindet und das> dokumentiert werden sollte.
Damit ist gemeint, dass sich an der Anzeige "--" als Wert einstellen
lässt. Für solche Felder müssen die Flags (1. Byte des Wertes) anders
gesetzt werden, siehe protocol.md. Diese Eigenschaft kann leider nicht
aus dem (get-)Telegram abgeleitet werden.
> Mit GitHub habe ich gedanklich gespielt. Je länger ich überlege, desto> mehr komme ich zur Überzeugung, dass speziell mir eine Datei nur im> Internet nichts nützt. ...
Die Besonderheit an git ist gerade, dass man das komplette Repository
als lokale Kopie vorliegen hat und mit dem Internet-Stand
synchronisieren kann. Bin auch noch am Lernen damit...
@Rolf:
Zumindest bei meiner ISR+ sind BZ mit zwei Anzeigen auch mit zwei
Telegrammen verknüpft. Typischerweise sind das Soll-+Aktualwert. Z.B.
8740+8741 = Raumtemperatur + RT-Sollwert.
> Die protocol.md ist herrvorragend.> Es gibt noch das Telegram type=8 [ERROR] und entsteht wenn z.B ein> illegales cmd (Field ID) abgesetzt wurde try 063D0D0518.
Falls Du mit github fit bist, freue ich mich über Pull-Requests. :)
Ansonsten probier ich das gelegentlich mal aus.
Viele Grüße,
Johannes
Anbei zwei Bilddateien: erstens der Schaltplan eines LP-Bus Interface
mit galvanischer Trennung zwischen Heizungsgeräten und
Datenverarbeitung; zweitens ein Bild des Aufbaus.
Ich hatte mehrere Gründe, zwei Varianten des seriellen Interfaces
einzubauen. Einer war der schon vorhandene Sniffer für RS232, den ich
mit seiner kommerziellen Software und meinen selbst geschriebenen Tools
weiter verwenden will, ein anderer Grund war die Stromversorgung der
Baugruppe aus dem USB-Anschluss des PC. Weiter oben habe ich die
Funktion schon beschrieben.
=====
Rückmeldungen zum Projekt bsbgateway
Datei protocol.md
Packet structure
Der Beschreibung stimme ich nicht zu. Ohne eine payload kommen genau 11
bytes framing data zusammen: Magic byte, source adrs, dest adrs, packet
len(=0x0B), telegram type, field ID (4 bytes), CRC (2 bytes). Die Datei
bsb_telegram.py in Zeile 108 weiß das ;-)
Paketlänge: Maximal darf ein LP-Bus Paket 32 bytes lang sein (versch.
SIEMENS Unterlagen, u.a. im ersten Forumsbeitrag zitiert). Folglich
kann ein Paket zwischen 0 und (32-11) = 21 bytes payload transportieren.
Bei 26 bytes Paketlänge errechne ich (26 - 11 bytes framing data) = 15
bytes payload.
Choice (selection lists):
Zitat: “The possible values can be found in the Systemhandbuch, at least
if the field is documented.” Welches Systemhandbuch?
Im übrigen grabe ich mich erst noch durch die umfangreichen
Programmdateien und versuche als Python-Anfänger DEN roten Faden zu
erkennen. Bis jetzt sind es einzelne Stücke, obwohl der Code sehr
sauber geschrieben und kommentiert ist (das erkennt man auch ohne tiefe
Kenntnisse der Sprache). MPEBCAT - My problem exists between chair and
terminal.
===
Raspberry serial interface
An einer Stelle steht, dass bsbgateway leicht auf den Raspberry
portiert werden kann (auf hick-ups bei der Portierung komme ich gleich).
Ich habe etliche meiner Raspberries mit einem MAX3232 Pegelwandler und
einem DB9 Anschluss versehen und fände den Kleincomputer für diese
Anwendung in der Tat recht praktisch.
Der Raspberry hat aber keine RS-232 Steuerleitungen wie z.B. RTS / CTS
und weiß deswegen nicht, ob das LPB-Interface seinen Datenstrom stoppen
will. Was übersehe ich da? Wie kann das Monoflop dann den Datenstrom
vom Raspberry aufhalten?
===
bsbgateway auf dem Raspberry (wenigstens erst 'mal zum sniffen. Da
steckt so viel Vorarbeit drin, dass es dumm wäre, wenn ich das Rad neu
erfinde)
Ich bekomme eine Fehlermeldung, wenn ich 'sh bsbgateway.sh' aufrufe:
ImportError: No module named web
Die Suche und auch die Installation des fehlenden Moduls gestalten sich
nicht ganz einfach.
1. Das fehlende Modul ist Bestandteil eines Pakets, das auf der Seite
http://webpy.org/ angeboten wird. Die Verfasser erklären, man brauche
"nur" aufzurufen
sudo easy_install web.py
2. Dummerweise fehlt auf meinem vanilla Raspbian easy_install. Woher
bekomme ich es?
https://pythonhosted.org/setuptools/easy_install.html#installing-easy-install
Man bekommt es mit setuptools https://pypi.python.org/pypi/setuptools
Erster Schritt: Get ez_setup.py
wget https://bootstrap.pypa.io/ez_setup.py -O - | python
Zweiter Schritt: Install web.py
easy_install web.py
===
Der Fehler mit dem modul web beim Ausführen von bsbgateway.sh ist nun
weg.
Wenn serial_port = 'fake' in config.py definiert ist, findet
single_field_logger.py”, line 121 den Pfad und die Logdatei
traces/8510.trace nicht. Lösung: Es reicht schon, das Verzeichnis
traces händisch anzulegen.
Ich wühle einfach 'mal weiter ...
Hallo Harald,
> Datei protocol.md
Deine Anmerkungen zur Länge sind korrekt. Ich habe die Fehler
korrigiert.
> Choice (selection lists):> Zitat: “The possible values can be found in the Systemhandbuch, at least> if the field is documented.” Welches Systemhandbuch?
Das genau dort verlinkte :-) welches irgendwo hier im Thread als Anhang
zu finden ist.
> Der Raspberry hat aber keine RS-232 Steuerleitungen wie z.B. RTS / CTS> und weiß deswegen nicht, ob das LPB-Interface seinen Datenstrom stoppen> will. Was übersehe ich da? Wie kann das Monoflop dann den Datenstrom> vom Raspberry aufhalten?
Ich habe bei mir einen USB-auf-RS232 Adapter von der Stange am laufen,
bei dem alle Pins korrekt angebunden sind.
Der Max232 hat (vom flüchtigen Blick aufs Datenblatt) nur einen Hin-und
Rückkanal. Die sauberste Lösung wäre wahrscheinlich einen zweiten MAX232
als Pegelwandler für die Statusleitung(en) einzusetzen und die TTL-Seite
an die GPIOs anzuschließen. Laut http://elinux.org/RPi_Serial_Connection
/ Abschnitt "Handshaking Lines" kann man bestimmte GPIO-Pins als
RTS/CTS-Pin konfigurieren.
> Die Suche und auch die Installation des fehlenden Moduls gestalten sich
nicht ganz einfach.
Die richtige Antwort hätte gelautet: sudo apt-get install python-webpy
Generell kriegt man bei Debian und seinen Kindern die meisten
(nicht-Standard)-Python-Libraries als Paket python-irgendwas.
> Lösung: Es reicht schon, das Verzeichnis traces händisch anzulegen.
Habe es gefixt: Verzeichnis wird automatisch angelegt wenn nicht
vorhanden.
Viele Grüße,
Johannes
[quote="Joachim"]Ich habe bei mir einen USB-auf-RS232 Adapter von der
Stange am laufen, bei dem alle Pins korrekt angebunden sind.[/quote]
Ja, die Möglichkeit böte mein LPB-Interface mit dem FTDI Platinchen
ebenfalls und ist auch schon dafür verdrahtet (siehe Schaltplan). Es
kann nur sein, dass ein Raspi für das Interface nicht genügend Strom
liefern kann.
Bei bisherigen Anwendungen des Raspi seriellen Interfaces brauchte ich
selbst bei 115,200 bps weder die DTE- noch die DCE-Seite einzubremsen.
Ein Raspi mit seriellem I/F sieht z.B. so wie im Bild aus; ein MAX3232
SMD-Chip samt SMD-Kondensatoren an den Beinchen klebt ohne Platine
kopfüber innen am Deckel. Ihren Hinweis auf die entsprechende
Mehrfachfunktion der GPIO-Pins habe ich mir jedenfalls abgespeichert,
danke! Damit ließe sich der Raspi am seriellen port dann mit einem
LP-Bus Interface verbinden.
Das mit dem automatischen Anlegen des Verzeichnisses ist eine schöne
saubere Lösung :-)
Erst mal ein herzlich Dank an Johannes Löhnert und dessen Arbeit!
Ich benutze auch einen Raspberry und eine leicht modifizierte Schaltung
von Johannnes.
Ich habe den Eindruck, dass die "Field ID" nicht vollständig
interpretiert wird. Aus meiner Sicht sind die ersten beiden Byte eine
"logische Adresse". Deshalb auch das drehen der beiden Bytes beim Senden
und Empfangen. Ich habe damit experimentiert und es funktioniert. Nur
bei der Zuordnung der "Logischen Funktionen" bin ich mir nicht sicher.
Hier mal ein Beispiel der Adr. 0x6D; habe ich mir so ausgedacht.
16:19:56.508 - DC 97 00 0B 06 6D 31 05 2F B7 36 = 11 Bytes
Source : 17 SW Control Unit
Destination : 00 Integrierter System Regler
Message type: 06 Query
From >>> To : 6D31 SW Bedieneinheit >>> Trinkwasser
Message Cmd : 052F Trinkwassertemperatur Anfrage
16:19:56.970 - DC 80 17 0E 07 31 6D 05 2F 00 0D E8 D9 5E = 14 Bytes
Source : 00 Integrierter System Regler
Destination : 17 SW Control Unit
Message type: 07 Answer
From >>> To : 316D Trinkwasser >>> SW Bedieneinheit
Message Cmd : 052F Trinkwassertemperatur = 55.62 °C
Data : 00 0D E8
Dann noch ein paar Infos, die ich bisher hier nicht gefunden oder
übersehen habe. Es geht um die einfache Programmierung der Zeiten für
Heizung und Trinkwasser. Hier das auslesen, setzen geht genau so
einfach.
Heizung: Montag .. Sonntag = 0A8C .. 0A92
Trinkwasser: Montag .. Sonntag = 0AA0 .. 0AA6
16:19:58.364 - DC 97 00 0B 06 6D 05 0A 8C 3B E4 = 11 Bytes
Source : 17 SW Control Unit
Destination : 00 Integrierter System Regler
Message type: 06 Query
From >>> To : 6D05 SW Bedieneinheit >>> Status
Message Cmd : 0A8C HK1 Vorwahl/Phasen Montag Anfrage
16:19:58.473 - DC 80 17 17 07 05 6D 0A 8C 06 1E 09 00 0C 00 17 00 98 00
18 00 12 3A = 23 Bytes
Source : 00 Integrierter System Regler
Destination : 17 SW Control Unit
Message type: 07 Answer
From >>> To : 056D Status >>> SW Bedieneinheit
Message Cmd : 0A8C HK1 Vorwahl/Phasen Montag Phase 1: 06:30 09:00
Phase 2: 12:00 23:00 Phase 3: --:-- --:--
Data : 06 1E 09 00 0C 00 17 00 98 00 18 00
Hier meine schwache Interpretation der "Logischen Adr." des ISR
0x05 Basis Parameter (Zeit, Vorlauf, ..)
0x06 ??
0x07 ??
0x09 ??
0x0D Gebläse / Schornsteinfeger
0x11 Pumpensteuerung
0x15 Relais ???
0x19 Heizkurve???
0x21 ??
0x22 ??
0x25 Zirkulation
0x2D Heizkreis 1 Parameter
0x2E Heizkreis 2 Parameter
0x31 Trinkwasser
0x49 Solar
Grüße Piet
Piet, Das hört sich nach einem weiteren Schritt nach vorne an! Heisst
das, dass die bisher katalogisierten FieldIDs mit P1/P2/P3/P4 nicht
statisch sind und nicht als feste Werte katalogisiert werden sollten,
oder nur mit einer Angabe, wer wohin sendet?
Johannes war einer derer, die ein maschinenlesbares, aber relativ
einfaches Format für die Telegrammdokumentation gefordert haben. Ich
stelle beispielhaft folgenden Ausschnitt (siehe PDF-Datei) aus einer
mehr als 10,000 Zeilen langen Dokumentation aller mir bekannten ProgNr
und Bedienzeilen zur Diskussion, die ich aufgestellt habe. Grundlage
waren bisherige Beiträge hier im Forum, z.B. in Spreadsheet-Form oder
als Textdatei, gedruckte Dokumentation sowie die Angaben, wie sie ein
Konfigurationsprogramm beim Anschluss an eine reale Anlage darstellt.
Sonderfälle: Nicht alle Parameter können gesetzt werden (write), und
nicht alle Parameter sind jederzeit sichtbar (Nullable). Es gibt
deswegen ein Attribut Writeable, das aber implizit True ist, es sei
denn, es wäre explizit als False vermerkt. In ProgNr 0700 ist es
beispielhaft dennoch eingesetzt. Ebenso verhält es sich mit dem
Attribut Nullable.
Frühere Schreiber haben z.B. Wärmepumpenanlagen dokumentiert; die
entsprechenden Parameter und Telegramme kann nur jemand nachvollziehen,
der die entsprechende Dokumentation und am besten auch die Anlage
besitzt. Ich kann es nicht, siehe den letzten Parameter in der Liste.
Da - und bei bisher nicht dokumentierten Parametern - ist Hilfe gefragt.
Erstens: Genügt diese Art der Dokumentation den Vorstellungen der Leser?
Sie ist in der Form von Python Kommentaren geschrieben ;-) und man kann
sie evtl. als maschinenlesbar bezeichnen. Sogar wir Menschen können uns
einen Reim darauf machen, denke ich.
Zweitens: Wenn ja, wer kann sich vorstellen, Ergänzungen vorzunehmen?
Drittens: Vorschlag einer Kollaborationsmethode?
Ahoi bsbBusFreunde,
Die Theorie von Piet eine weiteres SrcDest addressierung einzubauen,
macht aus meiner Sicht keinen Sinn, da es ja an anderer Stelle vorhanden
ist.
Auffällig is aber das bei seinen Telegrammen der Wert P2 (beim manchen
Telegrammtypen P1) 6D ist. Bei mir ist das eine 3D.
Meine Theorie basiert auf BZ:6226
Konfiguration/Objektverzeichnis-Version CMD:053D0004. Daher könnte P2
auf dieses Vervweisen.
Eigentlich sollte man den bsb bei einem Reset der AWS abhören. Eventuell
gibt es eine Art Handshake auf das Objektverzeichnis der LMU.
@Piet: kannst du mal die BZ6226 bei deiner Anlage auslesen ?
Piet:Zeitprogramm Heizkreis 1/Vorwahl 056D0A8C
mein:Zeitprogramm Heizkreis 1/Vorwahl 053D0A8C
Die Interpretation der Logischen Addr. (P1?) habe ich mit einer
sortierung meines Excel Sheet nicht nachvollziehen können. Wenn nach P3
sortiert ist es schon logischer, aber ich Vermute dass ein komplexeres
Schema vorhanden ist.
Schlussendlich müssen wir aber die cmd's nicht Gruppieren, sondern den
Typ für jedes Setting herausfinden und Anlagenübergreifend korrelieren.
gruss aus der schweiz
Hallo Freunde der Brötje Steuerung,
anbei die Antwort auf die Frage von Rolf
Piet:Zeitprogramm Heizkreis 1/Vorwahl 056D0A8C
0x05 ist die Adresse wo ich die Info herbekomme oder was setze
0x6D ist bei mir die logische Adress meiner SW Steuerung
DAs geht auch mit anderen Adressen.
mein:Zeitprogramm Heizkreis 1/Vorwahl 053D0A8C
0x05 ...
0x3D ist die logische Adress der Bedieneinheit
(fehlte leider in meiner Tabelle)
Die letzten vier Byte beinhalten das eigentliche Command.
Grüße Piet
Hallo Piet,
> Ich benutze auch einen Raspberry und eine leicht modifizierte Schaltung
von Johannnes.
Du hast hoffentlich den Hinweis bzgl. (fehlender) Potentialtrennung
gelesen?
Bzgl. der Felder habe ich folgende Beobachtungen gemacht: P1P2 wurde
anscheinend zur Gruppierung eingesetzt, P3P4 als fortlaufender Index.
Z.b. für die meisten Felder in Bezug auf Solarheizung ist P1P2 = 0x493d.
Oder vieles was mit Raumheizung zu tun hat hat 0x053d. Die Gruppierung
ist aber keineswegs deckungsgleich mit den Menüs (z.B. findet man die
0x493d unter Solar(3800) als auch unter Status(8400)) und die Menüs
enthalten fast immer auch mehrere "P1P2"-Gruppen. (Siehe
bsbgateway/bsb/broetje_isr_plus.py)
Aufschlussreich sind auch "kopierte" Felder. Z.B:
8740, u'Raumtemperatur 1' = 0x2d3d051e
8770, u'Raumtemperatur 2' = 0x2e3d051e (hier wurde das erste Byte P1
weitergezählt),
andererseits
8830, u'Trinkwassertemperatur 1' = 0x313d052f
8832, u'Trinkwassertemperatur 2' = 0x313d0530 (P4 weitergezählt).
Insgesamt sieht das für mich so aus, als ob man ursprünglich mit einem
geordneten Nummernsystem gestartet ist, und dann im Laufe der
Softwareentwicklung frei Schnauze weitere Nummern besetzt hat. M.m.n.
kann man das System nicht entschlüsseln, weil es einfach keins mehr
gibt.
Kodierung der Zeiten: siehe doc/notes.txt sowie doc/protocol.md - ich
stimme mit deiner Interpretation überein. Zu ergänzen ist noch dass die
Nullwerte ("--:--") durch Setzen des 0x80-Bits in der Startzeit kodiert
werden. (0x98 in deinem Dump).
Harald, bzgl. der Master-Feldliste:
- Ein definierter Trenner ("hier beginnt ein neues Feld") wäre günstig.
Im Zweifelsfall reicht die Regel dass die ProgNr immer als erstes kommen
muss.
- Ganz wesentlich: Angabe des Datentyps (bestimmt Bytelänge und
Interpretation des Feldes)
- Ich bin nicht sicher ob wir unter Nullable das selbe verstehen. Ich
meine damit die Feldeigenschaft, dass der Wert auf "--" gesetzt werden
kann.
- Es fehlt m.M.n. nach noch die Angabe des Divisors (z.B. 1/64 für
Temperatur, 1/3600 für Betriebsstunden, irgendwo gabs auch 1/10)
- Die Choices können u.U. sehr viele werden, und sind auch nicht
zwangsläufig fortlaufend numeriert. Siehe z.B. Feld 8010 in der
bsbgateway/bsb/broetje_isr_plus.py.
- Zusätzlich sollte die Zuordnung zu Gerät(en) und evtl. Menü erfasst
werden, das könnte man aber auch als Extraliste machen (Gerätename ->
Liste der Menüs -> jeweils Liste der ProgNr'n). Könnte aber zu
Scherereien kommen falls die selbe Prognr abweichend verwendet wird.
Ach ja, bitte meine Liste aus dem Quelltext nicht von Hand abtippen,
dafür schreibe ich natürlich ein Skript - sobald wir uns einig sind. :-)
Johannes L. schrieb:> - Ein definierter Trenner ("hier beginnt ein neues Feld") wäre günstig.> Im Zweifelsfall reicht die Regel dass die ProgNr immer als erstes kommen> muss.
Ja, so handhabe ich das; ProgNr ist immer der erste Eintrag eines
Datenpunkts.
> - Ganz wesentlich: Angabe des Datentyps (bestimmt Bytelänge und> Interpretation des Feldes)
Bis jetzt habe ich ein Schlüsselwort 'Unit' eingeführt. Weitere Angaben
dazu sind natürlich möglich. Diskussion en detail: siehe meinen letzten
Satz.
> - Ich bin nicht sicher ob wir unter Nullable das selbe verstehen. Ich> meine damit die Feldeigenschaft, dass der Wert auf "--" gesetzt werden> kann.
Ja, wir verstehen das Gleiche darunter. Um dieses Attribut zu sehen, bin
ich die Query-/Set-Dialoge in einem PC-Konfigurationsprogramm
durchgegangen. Dort gibt es für solche Datenpunkte noch einen button
'Aktivieren' bzw 'Deaktivieren' (so oder so ähnlich, kann je nach
Datenpunkt auch etwas anders heißen). Wenn der Button existiert, habe
ich das Attribut Nullable=True gesetzt.
> - Es fehlt m.M.n. nach noch die Angabe des Divisors (z.B. 1/64 für> Temperatur, 1/3600 für Betriebsstunden, irgendwo gabs auch 1/10)
So weit bin ich noch nicht. Ich habe noch kein einziges Telegramm auf
dem Schirm gehabt.
> - Die Choices können u.U. sehr viele werden,
Ja. Aber das macht einem Computer nichts aus. Die Definitionen der Aus-
und Eingänge (5890 ff) im Menu Konfiguration sind ein Leckerbissen.
> und sind auch nicht zwangsläufig fortlaufend numeriert.> Siehe z.B. Feld 8010 in der bsbgateway/bsb/broetje_isr_plus.py.
Oops. Das ist störend, ließe sich aber wie in einer C enum abbilden.
> - Zusätzlich sollte die Zuordnung zu Gerät(en)
Inwiefern? Busadresse? Menschenlesbarer Name?
Mein bisheriger Ansatz: Ich habe drei Geräte (Fernwartungs-Interface,
Regler ISR, Kesselregler) jeweils als Überschrift vermerkt. Zu beachten
ist aber, dass einige gleiche Datenpunkte sowohl im Regler ISR-SSR als
auch in der Kesselregelung auftauchen. Ich finde das nicht weiter
erstaunlich, da beide am selben Bus hängen, das eine Gerät mit dem
anderen redet, und beide zum Teil denselben Parameter zur Regelung
verwenden. Ich denke, die ISR wird zum Ober-Regler, sofern sie
vorhanden ist, andernfalls kann die Kesselregelung eine kleine Anlage
auch alleine steuern. So ist auch die Sicht des
PC-Konfigurationsprogramms auf die Anlage: drei Geräte, jedes mit
Menues, jedes Menu mit Datenpunkten. Menues und deren Datenpunkte
können in mehr als einem Gerät sichtbar sein. Anmerkung: Raumgeräte
tauchen nirgends auf.
> und evtl. Menü erfasst werden,
Ja, die Zuordnung zum jeweiligen Menu habe ich in Form einer Überschrift
vermerkt. Es gibt also bis jetzt drei Überschriften für die drei Geräte
und für jedes Menu eine Überschrift.
> das könnte man aber auch als Extraliste machen (Gerätename ->> Liste der Menüs -> jeweils Liste der ProgNr'n). Könnte aber zu> Scherereien kommen falls die selbe Prognr abweichend verwendet wird.
Die Möglichkeit anderer Zuordnungen bei anderen Herstellern habe ich
kurz überlegt und dann als hic et nunc irrelevant zurückgestellt. Da
habe ich Mut zur Lücke.
>> Ach ja, bitte meine Liste aus dem Quelltext nicht von Hand abtippen,> dafür schreibe ich natürlich ein Skript - sobald wir uns einig sind. :-)
Nein, ich gehe momentan ganz autark vor. Und vom Script-Schreiben werde
ich Sie keineswegs abhalten.
Was das Einig-werden zwischen uns angeht: Ich weiß nicht, ob wir das
Forum in diesem Stadium damit "langweilen" sollten und vielleicht
vorerst auf E-Mail ausweichen sollten. In dem "Einigungsprozess" werden
wir öfter eine Datei hin- und herschieben, bis alles nach Wunsch steht
und keine Fehler mehr erkennbar sind.
Schönen Gruss, Harald
Was den gewünschten Divisor und entsprechende Angaben angeht: ich nehme
das Beispiel Temperatur zur Erklärung. Mit der Angabe der Unit=degree,
einem Minimum- und Maximum-Wert sowie der Schrittweite, die ganze Grad
oder Bruchteile umfassen kann, ist das implizit abgedeckt, nicht wahr?
Entsprechend habe ich die Angaben für Prozent, float (Kesselsteilheit,
dimensionslos), Dauer in h, min oder sec formuliert.
Auswahllisten können ganz ähnlich wie Ihre Darstellung aussehen:
# ProgNr 8010
# Fieldname Status Pufferspeicher
# Writeable False
# Unit Choices
# Choice1 0: u'---'
# Choice2 202: u'Frostschutz Kühlen aktiv'
# Choice3 135: u'Sperrdauer nach Heizen'
# Choice4 81 : u'Ladung gesperrt'
# Choice5 124: u'Ladung eingeschränkt'
usw.
# Choice39 51 : u'Keine Wärmeanforderung'
# Default ?
# P1/P2/P3/P4 053D07AB
Dabei ist die laufende Nummerierung der einzelnen Posten nicht unbedingt
erforderlich.
Die Trennung von Geräten, Menues und Datenpunkten habe ich zudem noch
jeweils wie einen Python-Block eingerückt. Geräte beginnen in Spalte 1,
Menues in Spalte 3, Datenpunkte in Spalte 5. Beispiel:
# ================================================================
## FM-K GSM Fernwartungs-Interface OCI611
## Bezeichnung: Zentrale
## LPB-Adresse (Beispiel): Zentrale Segment 0 Gerät 5
# ================================================================
# Menu Zentrale
## Nummern wie im Konfigurationsprogramm, Anwendung Bedienbuch
dargestellt
.....
# ================================================================
## ISR-SSR C Solarsystem-Regler
## Bezeichnung: Regler
## LPB-Adresse (Beispiel): Regler Segment 0 Gerät 1
# ================================================================
# Menu Uhrzeit und Datum
# ProgNr 0001
# Nullable False
# Writeable True
# Fieldname Stunden / Minuten
# Unit hh:min
# Default 00:00
# P1/P2/P3/P4 ?HELPME?
....
# ProgNr 0710
# Fieldname Komfortsollwert HK1
# Nullable False
# Unit degree
# Min 18.0
# Max 35.0
# Step 0.5
# Default 20.0
# P1/P2/P3/P4 3D2D058E
....
# ProgNr 0720
# Fieldname Kennlinie Steilheit HK1
# Nullable False
# Unit Float
# Min 0.10
# Max 4.00
# Step 0.02
# Default 1.50
# P1/P2/P3/P4 2D3D05F6
....
# ProgNr 2446
# Fieldname Gebläseabschaltverzögerung
# Nullable False
# Unit sec
# Min 0
# Max 200
# Step 1
# Default 3
# P1/P2/P3/P4 053D3076
....
# ================================================================
## Kesselregler blabla
## Modell blublu
## Bezeichnung: Regler
## LPB-Adresse (Beispiel): Regler Segment 0 Gerät 2
# ================================================================
# Menu Uhrzeit
## This menu is addressable as Regler Segment 0 Gerät 1 (ISR-SSR)
## - OR - as Regler Segment 0 Gerät 2 (Kessel)
Die durch TABs getrennten Spalten rutschen hier im Text zusammen, sorry.
Heute habe zum ersten Mal dem LP-Bus einfach nur zugehört.
Merkwürdigerweise sehen die Telegramme ganz anders aus als hier
berichtet. Beispiel:
DCE starts at 236,035,592 us (+0 us offset) with:
87 ec 00 ff 03 fd ff eb fd ea ff fd f5 ff fe ff ................
ff 05 0e 34 ...4
Block length=20 (0x14) bytes
Pause of 7,403,486us at 243,482,625 us (+7,447,033 us offset):
87 f1 ff fb 3f fd ff eb 79 fa fa ff 9b 0a 9f ....?...y......
Block length=15 (0x0f) bytes
Pause of 33,586us at 243,548,286 us (+7,512,694 us offset):
87 e7 fb ff f3 fd ff eb 78 fa fa ff 9b ff a5 ff ........x.......
10 fc 08 ff ff 5d 2f 11 89 .....]/..
Block length=25 (0x19) bytes
Pause of 14,947,903us at 258,551,184 us (+22,515,592 us offset):
87 f1 fe fb 3f fd ff eb 59 fa fa ff 9b 0a 7e ....?...Y.....~
Block length=15 (0x0f) bytes
Pause of 28,962us at 258,612,234 us (+22,576,642 us offset):
87 e7 fb fe f3 fd ff eb 58 fa fa ff 9b ff 75 ff ........X.....u.
9b fc 17 ff ff 86 49 12 15 ......I..
Block length=25 (0x19) bytes
Pause of 7,054,398us at 265,726,628 us (+29,691,036 us offset):
87 ee 0f ff 03 fd ff eb fd e6 ff fe 02 ff f7 fc ................
0c 41 .A
Block length=18 (0x12) bytes
Pause of 1,149,165us at 266,914,757 us (+30,879,165 us offset):
87 ee 00 ff 03 fd ff eb fd e6 e6 fe 01 ff f7 fc ................
0c 18 ..
Block length=18 (0x12) bytes
usw.
Die Zeitangaben in Mikrosekunden beziehen sich jeweils auf das erste
Byte eines solchen Telegramms. Die Unterteilung in Telegramme muss
notgedrungen bis zu einem kleinen Grad willkürlich bleiben. Der Sniffer
ordnet jedem Datenbyte ein timestamp zu, was es mir gestattet, den
Datenstrom immer dann wie oben zu unterteilen, wenn die Pause zwischen
einem Byte und dem nächsten länger als (eine character time + 15%) ist.
Wenn die Pause kleiner ist, nimmt mein Sniffer-Analyseprogramm das
Zeichen noch zum derzeit laufenden Telegramm.
Der Sniffer ist auf 4800 bps 8-Odd-1 eingestellt und meldet keine
framing errors, Ein Oszilloskop misst eine bit time von 205 us, was die
4800 bps bestätigt. Momentan habe ich keine Erklärung, warum die Daten
auf dem LP-Bus so anders aussehen, auch nicht, wenn ich untersuche, wie
sie negiert oder mit reversed bit order aussehen (geht ja schnell 'mal
in Software) oder wenn ich versuche, CRCs zu verifizieren.
BSB / LPB Unterschied ?
- BSB und LPB sind Hardwarekompatibel
- Die Datentelegramme sind vom Aufbau gleich
- Ich steuere und lese über den BSB aus - einfacher im monovalenten
Betrieb
LPB wird eigentlich erst mit mehreren Erzeugern interessant. So wie ich
es noch im Kopf habe, sind aber nicht alle Daten auf dem LPB verfügbar.
Zitat aus mikrocontroller.net
Beitrag "Re: Unterschied LPB Local Process Bus und BSB Boiler System Bus ?"
- Der BSB ist interessanter als der LPB, weil lt. Systemhandbuch der
LPB quasi-extern und der BSB 'Heizungs-Intern' genutzt wird. Das
RGT/QAA7x verwendet auch den BSB.
- BSB und LPB sind ja lt. Spezifikation gleich also wird sich nur der
Appl. Layer unterscheiden.
Zitat aus mikrocontroller.net
Beitrag "Re: Brötje ISR Plus Kommunikation / LPB"
@Rolf S.: Der Gedanke unterschiedlicher application layer ist ja
möglich; aber welche Entwickler käme auf den Gedanken, für mehr als ein
Protokoll auf diesem Hardware-Bus jeweils eine eigene Software mit
Software Architektur, code reviews, test cases, build process,
Dokumentation, etc. zu schreiben? Ich weiß, die meisten dieser Punkte
kann man ja stark einschränken böse. Das merkt man dann auch am
Ergebnis. An einen solchen Bus haengt der freundliche :-)
Wartungsmensch ja auch sein OCI700 und einen Schlepptop, in dem ein
Programm die Regler der Anlage, deren Menues und darin die Datenpunkte
darstellt. Und diese Verbindung und Darstellung sowie Änderungen der
Parameter müssten dann sowohl an einer Heizung mit einem Bus nach
application layer A funktionieren, genau so wie an einer Heizung mit
application layer B, C, ..?
Ich habe auch an die (natürlich beliebig weit entfernte) Möglichkeit
gedacht, dass die Triggerschwelle der Eingangsstufe die Buspegel nicht
korrekt den High-/Low Werten zuordnet. Dafür kommen mir die Daten aber
zu wiederholbar (wiedererkennbar) vor. Eine zufällige falsche
Zuordnung einzelner Bits würde sich in "data noise" zeigen.
Momentan stehe ich vor einem Rätsel. Warum sollte ausgerechnet (m)eine
Anlage die einzige sein, die ein anderes Bus-Protokoll fährt als alle
hier bisher vorgestellten Anlagen? Meine Anlage besteht aus einem
Heizkessel mit seiner eingebauten Steuerung, per Bus verbunden mit einer
ISR-SSR Steuerung, die wohl der master des Ganzen ist und die auch eine
Solaranlage steuert.
Ahoi brha (GAST),
Punkt1: Es wird meist nicht auf der grünen Wiese Entwickelt.
Kompatibilität und mehr Funktionalität sind gerne in einem
Anforderungskatalog.
Ich habe mal ein paar RVL's per LPB vernetzt, das sind schon fast antike
Steuereungen - aber funktionieren auch noch heute :-)
Meistens ist die Aufgabe eines "Wartungsmenschen" - die anlage am leben
zu erhalten und wehe es ist mal kalt.
Punkt 2:
Bei mir habe ich ab und zu noch CRC errors. Dies ist sehr hilfreich bus
fehler zu erkennen :-). Wenn ich mal Zeit habe, werde ich wohl
versuchen, mit einem KO bewaffnet, den Fehler zu reproduzieren.
Punkt 3:Verrate uns doch mal was für eine Steuerung bei dir eingebaut
ist. Dazu gibt es auch wohl auch Doks wo beschrieben ist auf welcher
Klemme welche funktion zu finden ist.
Du wirst schnell festellen, dass man sehr viele möglichkeiten hat.
Auch wäre es interessant, das LPB addressierungschem deiner Anlage zu
kennen.
Versuch doch mal einzelne Telegramme einer bestimmten ServiceTool Zeile
zuzuweisen und hier zu posten.
gruss aus der schweiz
Ahoi brha,
Ich hab mal 20min verschwendet.
Frage:Was ist eine ISR_SSR und wo ist da BSB ?
Task : Google: ISR-SSR
File :Montageanleitung ISR SSR - TheKeSo.de / Seite 8:
Anwendungsbeispiel 1: studiert. Aha
Seite 9:Anschlussplan aha
eventuell eine LMU74xxx und eine RVS65xxx(wohl mit irgendeiner AVSxxx)
PS:Meistens sind hinter den Elektrokomponenten Barcodes mit der genauen
Siemens Typenbeschreibung aufgeklebt.
Zitat brha:
Momentan stehe ich vor einem Rätsel. Warum sollte ausgerechnet (m)eine
Anlage die einzige sein, die ein anderes Bus-Protokoll fährt als alle
hier bisher vorgestellten Anlagen? Meine Anlage besteht aus einem
Heizkessel mit seiner eingebauten Steuerung, per Bus verbunden mit einer
ISR-SSR Steuerung, die wohl der master des Ganzen ist und die auch eine
Solaranlage steuert.
Antwort(spekulativ):
Du hast zwei Steuereinheiten, welche mit einer Wärmeanforderung über lpb
gekoppelt sind.
ich gehe jetz raus an die herrliche Frühlingssonne.
Mir kommt ein Verdacht. Es gibt offensichtlich an ein und derselben
Steuerung zwei Buses: LPB und BSB. Beide sind nur auf Layer 1 identisch.
Der Titel des Forums hat bei mir gedanklich den Schalter auf "LPB"
umgelegt, aber offensichtlich schwenkte die Diskussion und Datenanalyse
dann ausschließlich auf den BSB um.
@Rolf S.
Das "etwas-genauer"-Bild hat die Glocke zum Schalter-Umlegen bei mir
geläutet. Darin sehe ich am SSR Solarsystemregler ISR-SSR-RVS65.583
einen Anschluss für den LP-Bus ganz links oben, der sich bei Montage der
ISR-SSR mit Gehäuse innerhalb des Wandgehäuses befindet. Auf den habe
ich mich bisher bezogen und habe mein Interface daran angeschlossen.
Was die Fragezeichen in Ihrem Bild angeht: Über die Bustechnologie der
BE (Bedieneinheit) und FB (Fernbedienung) kann ich keine Aussage machen.
Die Klemmenbezeichnungen CL- und CL+ beim Bus FB könnten auf einen Typ
BS-Bus hindeuten.
Die Verbindung zwischen SSR Solarsystemregler und Kesselregler geht über
einen LP-Bus. Es gibt Kesselregler, bei denen ein Busmodul CIB C oder
Busmodul BM zwischengeschaltet ist, sowie z.B. den Kesselregler
ISR-RVS43.122/100, der selbst einen LP-Bus Anschluss hat und kein
Busmodul braucht. Jedenfalls sieht es nicht so aus, als ob die Kessel
über den BSB mit dem Rest der Anlage kommunizieren. Zudem sind alle
Anlagenteile mit dem Service Tool OCI700 über einen der LP-Busanschlüsse
auslesbar und, wo vorgesehen, programmierbar. Auch das waren Gründe,
weshalb ich hier nur "LPB" gedacht habe.
Im dem "etwas-genauer"-Bild sind rechts neben dem LB-Bus-Anschluss
weitere Busanschlüsse, von denen zwei mit "BSB" gekennzeichnet sind. Die
werde ich mir jetzt vornehmen und denke, dass ich dann über dasselbe
rede wie die anderen Schreiber hier. Wenn ja, dann haben Sie mich auf
den richtigen Weg geführt.
> Antwort(spekulativ):> Du hast zwei Steuereinheiten, welche mit einer Wärmeanforderung> über lpb gekoppelt sind.
Dem kann ich nicht widersprechen. Haben denn die anderen Schreiber alle
nur Anlagenkomponenten, welche über den BS-Bus gekoppelt sind?
Die Frage ist, ob ich jetzt nur über den LPB-Anschluss an Daten der
Anlage komme oder ob sie auch über den real vorhandenen, aber nicht
verwendeten BSB-Anschluss einsehbar sind. Mal sehen, was sich an den
BSB-Klemmen tut ;-)
Rückmeldung:
Die beiden BS-Bus Anschlüsse sind bei meiner ISR-SSR Regelung zwar
unbenutzt, dennoch kann ich die Anlagendaten an diesen Klemmen mitlesen
/ auslesen.
Zweitens: Es gibt offensichtlich auch einen record type 05. Das folgende
Telegramm trat drei Mal auf, während ich verschiedene Einstellungen
ausprobiert habe. Die lesbaren Angaben darunter hat wein Analyseprogramm
dazugestellt. Der CRC ist korrekt.
dc 80 0a 0c 05 0d 3d 09 2a 06 f9 0d
Data point is Schornsteinfegerfunktion (7130).
Src=00 Dest=0a Type=unknown FieldID=0d3d092a Payload=06 CRC=0xf90d
In der aus vier Bytes bestehenden FieldID drehen die Broetje Steuerungen
die Reihenfolge der ersten beiden Bytes zwischen Anfrage und Antwort um.
Eine Dokumentation der FieldIDs z.B. in einer look-up Tabelle muss aber
eindeutig sein.
Gibt es bei den hier Schreibenden eine ggf. stillschweigende
Übereinkunft, in welcher Reihenfolge die Bytes der FieldID z.B. in einer
großen Tabelle aller Datenpunkte, ProgNr und den zugehörigen FieldIDs
stehen sollen: In der Reihenfolge der Anfrage oder in der Reihenfolge
wie in der Antwort?
Falls jemand über das Netzwerk oder das Internet auf ein entferntes
USB-Gerät zugreifen will, dann funktioniert das zum Beispiel mit
VirtualHere. www.virtualhere.com
Man kann sich vorstellen, damit z.B. über das Internet ein OCI700
anzusprechen, das irgendwo in der Welt an einer Anlage hängt.
Gerhard,
tut mir leid, dass Sie warten mussten, ich bin nur noch selten hier.
Nur zum Mitschneiden der Busaktivitaet braucht man kein OCI700, da
reicht eines der hier im Forum beschriebenen Interfaces wie z.B ich es
==> hier Beitrag "Re: Brötje ISR Plus Kommunikation / LPB" beschrieben
habe. Einfachere Loesungen haben zum Teil keine galvanische Trennung
zwischen Heizung und Computer, wovon ich dringend abrate.
Ein solches Interface kann man entweder an den LP-Bus oder an den BS-Bus
anschliessen, denn beide Buses haben die gleichen elektrischen
Parameter. Weder fuer den einen wie fuer den anderen Bus braucht man
die speziellen Steckverbinder von Broetje; fuer den BS-Bus nimmt man
Flachstecker-Verbinder 6.35 mm. Mit dem weiblichen Gegenstueck zu einem
Pfostenverbinder im Rastermass 2.54 mm kann man sich selbst einen
Anschluss an den LP-Bus zusammenloeten.
Das OCI700 Service Tool zusammen mit dem SIEMENS Konfigurationsprogramm
ist ein umfangreiches Biest; das LP-Bus Protokoll zu analysieren ist
dann eine ganz neue Aufgabe, an die sich keiner bisher gemacht hat, denn
alle zapfen den BS-Bus an. Was bei der Bestimmung der Parameter fuer
einen Datenpunkt aber oft hilft, egal ueber welchen Bus es gehen soll,
ist deren Darstellung im Konfigurationsprogramm. Man sieht, ob der
Parameter ueberschrieben werden oder nur abgefragt werden kann und, wenn
beschreibbar, ob er komplett de- und reaktiviert werden kann. Bei
manchen Werten ist ein Schieberegler abgebildet, woran man die
einstellbaren Maximal- und Minimalwerte ablesen kann. Trotzdem bleibt es
ein proprietaeres System und noch ausreichend viel zu tun, denn die
vorhandene Dokumentation ist lueckenhaft.
Wenn Sie ueber den LP-Bus den Inhalt von Datenpunkten aendern wollen,
dann fuerchte ich, brauchen Sie eine Sendemoeglichkeit, beispielsweise
das Konfigurationsprogramm und den OCI700 Adapter. Mit dem Wissen der
LP-Bus Kommandos koennte man aber auch ein Selbstbau-Interface
verwenden.
Bei meiner Entwicklung einer Hard- und Software als BS-/LP-Bus
Zwischengesicht ist ein Programm entstanden, das (a) den Mitschnitt der
BS-Bus Kommunikation analysiert und übersichtlich ausgibt und (b) über
serielle PC-Ports meinem BS-Bus Interface eine real existierende Heizung
vorspiegelt, die auf Anfragen sinnvoll antwortet. Die
Anfrage-Telegramme und die Antwort-Telegramme, die "von der Heizung
kommen" nimmt das Programm aus einem früher einmal an der Heizung
erstellten Mitschnitt des Bus-Verkehrs. Man kann so ein BS-Bus Interface
am Labortisch in beiden Richtungen austesten.
Die Schreib-Verbindung zum "Bus-Draht" werde ich als Nächstes
herstellen. Es wird einfach ein MOSFET sein, der den Buspegel
entsprechend dem seriellen Bitstrom von einem der seriellen PC-Ports mit
4800 bps moduliert. So "antworten" die simulierten Heizungsgeräte auf
die GET- oder SET-Kommandos vom BS-/LP-Bus Interface, das die
"Antworten" wiederum empfängt.
Wer es ausprobieren will: die tar-Datei in einem eigenen Verzeichnis
auspacken und
1
tar xzf analysis_pz.tgz
2
analyzeBus.py D-E.dat
ausführen.
Hinweis: Das Programm ist für Python 2.7 geschrieben und nur unter Linux
getestet.
Die D-E.dat Datei ist von einem Analysator für serielle Verbindungen
namens EZTap Pro (http://www.stratusengineering.com/) erzeugt worden.
Was darin steckt, steht in lesbarer Form in der D-E-ana_dat.txt
Ausgabedatei des Programms. Sie liegt bei, falls jemand nicht Python
installieren will. Zum Mitschneiden braucht man nur einen Bus-Adapter
mit Lesezugriff und natürlich den RS232-Analyser.
UNIT-TEST
Zusätzlich zur Analyse, die den Busverkehr formatiert ausgibt
(festgehalten in der Datei D-E-ana_dat.txt), kann man einen
Unittest-Modus zuschalten. Dann bedient das Programm zwei serielle
PC-Ports und generiert aus der Logdatei Anfrage-Telegramme und die
zugehörigen Antwort-Telegramme. Dafür muss das BS-Bus Interface den
Schreibmodus beherrschen, den man aber zuerst einmal ohne Gefahr für die
Heizung am Schreibtisch mit einem simulierten Bus testen kann.
Das Programm kann im Unittestmodus eine Logdatei namens UT-log.txt (in
der tar-Datei) schreiben, in der die Telegramme nachzulesen sind, die
über das BS-Bus-Interface "mit der Heizung" ausgetauscht wurden.
Hallo zusammen,
der FHEM-Thread, in dem eine ähnliche Lösung auf Arduino Mega 2560-Basis
entwickelt wurde, ist ja weiter oben schon erwähnt worden. Ich wollte
hier nur kurz kundtun, dass ich eine Kleinserie an PCB-Platinen habe
anfertigen lassen. Wer also ungern auf Lochraster aufbaut oder nicht
selber Platinen ätzen lassen will, kann ein der übrigen von mir samt der
nötigen Bauteile bekommen. Weiter Infos und Bilder gibt es "drüben":
https://forum.fhem.de/index.php/topic,29762.msg489266.html#msg489266
Gruß,
F.
Hallo Zusammen,
wie ist denn die CRC Berechnung für folgendes Telegamm:
0x78 0x10 0xff 0x0 0xfc 0x2 0x0 0x14 0x2 0x5 0x0 0x0 0x6b 0xa 0x6 0xf4
0x29
wobei hier die CS 0xf4 0x29 wären.
Vielen Dank für die Unterstützung
Ahoi
https://www.lammertbies.nl/comm/info/crc-calculation.html
CRC-CCITT (XModem)
payload 7810ff00fc020014020500006b0a06f429 ->0x22E7
payload 7810ff00fc020014020500006b0a06 -> 0xE70C
Dein paket scheint mir aber kein bsb bus telegramm zu sein.
gruss
Hallo Rolf,
zunächst mal schönen Dank für die Info. Ich habe die CRC-Berechnung
schon programmiert, besser gesagt kopiert, und diese bringt genau die
CS welche Du auch ermittelt hast.
Vielleicht zu meinem Aufbau: Ich habe ein Eurocontrol M Steuerung an
deren Ausgang (auf der Frontseite) einen Pegelwandler die Umsetzung auf
RS232 macht.
Protokoll mäßig hätte ich LPB Datenpakete erwartet mit der ganzen CRC
Berechung.
Allerdings kann ich nur Datenpakete ähnlich der von "brha (Gast) vom
25.03.2016 19:54" mitschreiben
Aufmerken ließ mich die Aussage von Johannes Löhnert (loehnertj) vom
22.03.2016 20:13 der u.a. etwas zu eine CRC sagte. Und ich wollte wissen
ob und ggf. wie er diese berechnet hat.
Gruß in die Schweiz
Alfons
Hallo, bitte aufpassen! LPB und BSB sind ähnlich, aber nicht gleich. Die
Protokolle sind anders.
7810ff00fc02... ist ein LPB Protokolldatensatz. Das kann ich bestätigen.
Hab ich auch entdecken können an meiner Anlage. Wie die CRC ermittelt
wird, weiß ich leider auch nicht.
Hallo, der Datensatz ist auch zu kurz. Da fehlt was. Probiert die CRC
mal an dieser Zeichenfolge (dezimal)
xxxxx
120 16 255 0 252 2 0 20 2 5 0 0 105 48 0 244 71 255
xxxxx
71 und 255 sind evt. die CRC.
und von oben
payload 7810ff00fc020014020500006b0a06f4
danach die CRC berechnen
Grüeziwohl alfons
eventuell muesch mol a dire RVA 46.531/100(siemenslandis&co-steit hinge
dran)
dr pin A6/MD (ruumfüehler)ahschliesse :-) - das isch zimli sicher en bsb
bus.
Grüezi Rolf S. ! RVA 46.531 hat keinen BSB ! Schau mal in das / Dein
Handbuch:
Kapitel: 2.2 Elektrische Installation, ...
MD Masse PPS (Raumgerät, BMU) AGP2S.02G blau
A6 PPS (Raumgerät, BMU)
PPS hat noch ein anderes Protokoll als LPB und BSB.
PPS = Punkt- zu Punkt-Schnittstelle
Hallo Zusammen,
obwohl ich in der Nähe der Schweizer Grenze wohne hatte ich etwas Mühe
mit Rolf's "Hochschweizerisch". Aber zunächst euch einfach mal vielen
Dank.
Also wenn ich Rolfs Vorschlag richtig verstanden habe, soll ich mal ein
Oszi an diese Schnittstelle hängen und prüfen ob dort etwas rauskommt,
das dem entspricht was 90% der TN empfangen.
@LPB-BSB
würdest Du da keine Signale erwarten?
Vor Jahren hatte ich mal ohmisch einige Pins durchgemessen und ich war
der Meinung dass die Pins auf der Frontseite auch hinten verfügbar sind.
Ich werde das einfach mal probieren.
Euch noch herzlichen Dank, werde über die Erfolge oder Misserfolge
berichten.
@LPB-BSB
würdest Du da keine Signale erwarten?
Hallo, das habe ich nicht geschrieben. Die Spannungspegel sind ähnlich.
Die Protokolle aber anders aufgebaut, auch wenn im Prinzip
ähnliche/gleiche Informationen übertragen werden.
@Alfons: Probiere doch bitte mal die CRC´s zu meinem Beitrag: 11.10.2016
21:53 zu ermitteln. Ich habe im Moment leider keine Zeit mich da
einzuarbeiten.
Hallo LPB-BSB,
ich bin heute leider krank, werde das mit der CS jedoch probieren. Danke
für die Unterstützung und noch einen schönen Abend.
Gruß
Alfons
Hallo,
super Informationen in diesem Thread.
Auch ich versuche unsere Brötje Heizung auszulesen, und habe mich auf
die
BS-Bus gehängt.
Ich empfange immer 2 Telegramme auf dem Bus, aber die passen nur zum
Teil zu dem was ich hier gelesen habe.
Die Telegramme die ich sehe sind folgende:
0xdc,0x2a,0x05,0x0b,0x1a,0x3d,0x36,0x16,0x19,0x3e,0xca,0x00
0xdc,0x04,0xa9,0x0e,0x3c,0x6c,0xec,0x64,0x00,0x19,0x04,0xc,0x2b,0x6f
0xdc,0x2a,0x05,0x0b,0x1a,0x3d,0x36,0x16,0x19,0x3e,0xca,0x00
0xdc,0x04,0xa9,0x0e,0x3c,0x6c,0xec,0x64,0x00,0x19,0x04,0xa,0x7b,0x9f
Da passt allerdings der CRC nicht.
Hat das schon mal jemand gesehen?
Ich zweifel gerade an meinem Hardware Adapter, wobei ich dann irgendwie
abweichende Telegramme erwarten würde, ich sehe aber immer genau das
gleiche.
Gruß
Arne
Hier wurde des öfteren die Frage gestellt, ob es nicht eine geschlossene
Darstellung der Kommandos und ihrer Parameter gibt; verschiedene
Benutzer haben unterschiedliche Darstellungen verwendet.
Hier ist noch eine Darstellung, welche die Kommandos mittels XML
zusammenfasst. Sie beruht großenteils auf der Vorarbeit diverser
Schreiber im FHEM-Forum.
ACHTUNG: Diese Datei ist zeigt die Daten beispielhaft und erhebt weder
Anspruch auf Vollständigkeit noch auf Richtigkeit. Sie ist mittels
eines Programms erzeugt worden, das nicht ganz die Intelligenz eines
Bedieners hat ;-)
Die beiden Dateien im vorigen Beitrag sind wegen eines Fehlers beim
Hochladen nicht die richtigen. Hier ist eine, die schon einmal
XML-syntaktisch besser ist ;-)
Hallo,
Da wir große Probleme mit einer Brötje SensoTherm BSW-K haben, die
Brötje und unser Heizi nicht lösen können, bin ich dabei unsere Anlage
zu überwachen/belauschen. Gibt es ein Möglichkeit, die Hardware/das
Interface irgendwo käuflich zu erwerben ? Oder eine empfohlene Version,
die man umkompliziert selbst bauen kann ?
Ich würde mal mit bsbgateway anfangen wollen.
https://github.com/loehnertj/bsbgateway
mfg,
SH
Hallo,
@F ... Haben Sie noch Bausätze ? Dann würde ich einen nehmen.
mfg,
SH
Freetz schrieb:> Hallo zusammen,>> der FHEM-Thread, in dem eine ähnliche Lösung auf Arduino Mega 2560-Basis> entwickelt wurde, ist ja weiter oben schon erwähnt worden. Ich wollte> hier nur kurz kundtun, dass ich eine Kleinserie an PCB-Platinen habe> anfertigen lassen. Wer also ungern auf Lochraster aufbaut oder nicht> selber Platinen ätzen lassen will, kann ein der übrigen von mir samt der> nötigen Bauteile bekommen. Weiter Infos und Bilder gibt es "drüben":> https://forum.fhem.de/index.php/topic,29762.msg489266.html#msg489266>> Gruß,>> F.
Hallo,
@F ... Haben Sie noch Bausätze ? Ich würde auch gerne einen kompletten
nehmen.
mfg und schöne Weihnachtstage,
FRH
Freetz schrieb:
> Hallo zusammen,>> der FHEM-Thread, in dem eine ähnliche Lösung auf Arduino Mega 2560-Basis> entwickelt wurde, ist ja weiter oben schon erwähnt worden. Ich wollte> hier nur kurz kundtun, dass ich eine Kleinserie an PCB-Platinen habe> anfertigen lassen. Wer also ungern auf Lochraster aufbaut oder nicht> selber Platinen ätzen lassen will, kann ein der übrigen von mir samt der> nötigen Bauteile bekommen. Weiter Infos und Bilder gibt es "drüben":> https://forum.fhem.de/index.php/topic,29762.msg489...>> Gruß,>> F.
Hallo in die Runde,
ich habe noch etwas gefunden:
http://www.grundwerk.info/static/bsb-interface.php
Weiß jemand aus der Runde, ob das ein sinnvoll nutzbares Teil ist?
Scheint ja noch im Entwurfsstadium zu sein...
Frohe Weihnachten,
Oliver
Hallo,
Ich hatte dieser Tage Kontakt mit dem Entwickler dieser Hardware. Auf
der Webseite sei noch der Prototyp beschrieben. Die Hardware sei nun
final und sollte mit https://github.com/loehnertj/bsbgateway
funktionieren.
Bausätze sind wohl bestellbar. Der Entwickler antwortet schnell auf
E-Mails.
Ich werde mir einen Bausatz bestellen und bsbgateway probieren.
Einfach mal Kontakt mit dem Entwickler aufnehmen.
LG
SH
Hallo Sebastian und Frank,
tut mir leid für die späte Antwort, ich lese hier nicht so häufig mit
und konzentriere mich auf das FHEM-Forum. Es sind aber noch Bausätze
vorhanden und von "unserer" Software gibt es inzwischen auch ein
GitHub-Repository, wo die jeweils aktuelle Software zu finden ist, so
dass man sich nicht durch 40 Seiten Thread durchwühlen muss ;)...
https://github.com/fredlcore/bsb_lan
Wenn noch Interesse an einem Bausatz besteht, dann bitte am besten eine
E-Mail an bsb (ät) code-it punkt de schicken.
Gruß,
F.
...nur damit keine Verwirrung aufkommt: Es handelt hierbei nicht um die
Bausätze von Grundwerk. Die von mir genannten sind aus besagtem
FHEM-Thread hervorgegangen und sind z.Z. auf dem BSB-Bus ausgelegt und
bisher an Brötje und Elco Thision Geräten im Einsatz.
Kurzes Update. Arduino Mega R3 + EthernetShield + Hardwareboard von
feetz lässt sich problemlos zusammenstecken.
Wie weiter oben beschrieben gibt es die 4polige Servicebuchse. Dort ist
CL+ auf Pin2 (von oben) und CL - auf Pin3 (von oben).
In die Servicebuchse passt ein 4poliger PC-Lüfterstecker perfekt rein.
Siehe z.B. http://www.elektronik-kompendium.de/sites/com/1503111.htm
Von github bsb_lan runterladen, IP festlegen und dann lässt sich die
Webseite mit Parametern bereits im Browser aufrufen.
Zumindest für meines Wärmepumpe Brötje BSW fehlen da in BSB_LAN noch
Werte. Besonders interessant der Abschnitt "Diagnose Erzeuger"
Mithelfen kann man indem an in der Arduino IDE den Seriellen Monitor
startet, auf Baudrate 115200 Baud stellt und am ISR Regler dreht.
Dann kommen über den BUS Telegramme, die man in BSB_LAN einpflegen muss.
Dazu gibt es u.a. einen Thread unter
https://forum.fhem.de/index.php/topic,29762.75.html
Achja,
Wer keine Steckdose für das Arduino-Netzteil neben der Heizung hat ...
Gut funktioniert bei mir POE. Dann kommt der Strom übers Ethernet-Kabel.
Als POE-Splitter hab ich den PoE Splitter 1 Gbit/s IEEE 802.3af TP-LINK
TL-PoE10R
Ich bastle gerade Zeug, um meine Broetje-Heizung vom Rechner aus steuern
zu koennen, und dabei habe ich etwas herausgefunden, was sonst wohl noch
niemandem aufgefallen zu sein scheint, daher will ich es mal hier mit
dranhaengen:
Eine Byte der "Feld-ID" ist nicht Teil der Feld-ID, sondern effektiv
eine Nachrichtenreferenz. Jedenfalls verhaelt es sich in all meinen
Tests so.
Nehmen wir z.B. das Feld 700 (Betriebsart Heizkreis 1), das steht in der
broetje-xml.xml oben ja als 2D3D0574. Das Byte "3D" ist allerdings gar
nicht relevant. Wie ja schon andere festgestellt haben, werden die
ersten beiden Bytes zwischen Anfrage- und Antwort-Nachrichten getauscht,
als wenn es sich um eine Art Sub-Adresse handelt. Und dazu passend wird
das zweite Byte in diesem Format von der Relegung auch einfach nur in
die Antwort kopiert, der Wert ist vollkommen egal.
Das mit dem kopieren des zweiten Bytes nach 3D war mich auch
aufgefallen.
Zur Sicherheit referenziere ich mal was mir an "Quellen für die
Telegrammdekodierung" bisher untergekommen ist
1) https://github.com/fredlcore/bsb_lan/blob/master/FAQ.md
2) https://github.com/loehnertj/bsbgateway/blob/master/doc/protocol.md
Es gab inzwischen eine Diskussion zwischen den Machern von BSB_LAN und
bsbgateway bezüglich Anbindung der Platine von freetz (s.o.) an
bsbgateway. Daraus enstand die Idee, die/eine Platine auch für die
Nutzung mit einem Raspberry PI nutzbar zu machen.
Ich habe inzwischen eine ganze Reihe Telegramme für eine Brötje_WP
(Bereich "Diagnose Erzeuger") in meine Kopie von bsb_lan eingefügt. Muss
nochmal alles geprüft werden aber wird dann hoffentlich in bsb_lan
einfliessen.
Letzte Tests zeigen, dass die Arduino-Lösung auch gut mit einem
Ethernet2-Shield funktioniert. Muss man die lib "Ethernet2" einbinden.
Das Shield hat auch direkt POE und daher ist ab jetzt nur noch ein
Netzwerkkabel nötig (Daten und Strom)
An S. Hilbert:
Sie beschreiben einen Luefterstecker, der in die sogenannte
Servicebuchse passt. Das ist eine praktische Entdeckung, falls man
nicht das dafuer passende Spezialkabel besitzt. M.W. ist diese fuer
einen solchen Stecker vorgesehene Buchse mit dem LP-Bus verbunden und
nicht mit dem BS-Bus, denn an dieser Buchse wird auch das SIEMENS
Service Tool OCI700 eingesteckt.
Beide Arten der internen Bus-Anschluesse der ISR-SSR sind in einem
Beitrag oben im Bild dargestellt; hier ist der Verweis zum obigen Bild:
http://www.mikrocontroller.net/attachment/288489/ISR-SSR-etwasgenauer.jpg
Die ganz links gezeigte und mit "LPB" gekennzeichnete Buchse an der
ISR-SSR Steuerung nimmt einen solchen Spezialstecker auf. Mehr zur
Mitte hin finden sich die mit "BS-Bus" bezeichneten Kontakte; es handelt
sich um 6.3 mm Flachstecker. Dafuer gibt es im Elektro- und KFZ-Handel
die bekannten Gegenstuecke.
Meines Wissens sind die externen Servicebuchsen (z.B. am Kessel), in die
der Spezialstecker passt, mit dem LP-Bus verbunden.
Hallo,
Vermutlich ist an der Servicebuchse sowohl BSB als auch LPB anliegend.
Mir ist mindestens eine Anlage (Brötje WP) bekannt bei der an der
Servicebuchse alle notwendigen Informationen (Pegel?) anliegen um damit
über bsb_lan und die passende Hardware (Arduino plus Platine) die
Parameter auszulesen.
An der selben Buchse war aber auch schon ein Brötje-Techniker dran mit
OCI 700 dran.
Servicebuchse hat den Vorteil, dass man die Hardware anschließen kann
ohne, dass man innen an den ISR-Plus selbst ran muss. Für schnelle
Diagnosezwecke. Jeder gut aufgestellte Heizi hat sicher die
Profi-Variante direkt von Siemens in der Tasche.
Ist vermutlich auch immer eine Frage wie der Heizi reagiert wenn
(während der Garantiezeit) der Endkunde direkt am ISR-Systemregler
irgendwelche Hardware anschließt.
Die Arduino-Variante läuft an der betreffenden Anlage seit Wochen 24/7
stabil. Alle 5 Minuten wird per cronjob das komplette Set an Parametern
ausgelesen (dauert 2 Minuten), Werte in sqlite-Datenbank geschrieben und
dann grafisch dargestellt (plot.ly)
Derzeit muss bei dieser Variante natürlich noch ein Rechner laufen, der
24/7 die Werte abruft (Kann ein RPi sein) und zwischenspeichert.
Zukünftig könnte bsb_lan so erweitert werden, dass die Werte direkt an
einen IOT-Server (z.B. Conrad Connect) geschickt werden.
Alternativ könnte man die Platine so verändern, dass sie direkt mit dem
RPI spricht. Da wird wohl schon dran gearbeitet von Freetz und Johannes.
[quote]Alternativ könnte man die Platine so verändern, dass sie direkt
mit dem RPI spricht. Da wird wohl schon dran gearbeitet von Freetz und
Johannes.[/quote]
Das ist auch mein Gedanke schon gewesen, allerdings unter einer
bestimmten Voraussetzung (s. weiter unten). Wo bleibt dann die
Intelligenz des Arduino-Programms? Soll das der PPi mit einem neu zu
schreibenden Programm uebernehmen?
Das saehe ich dann als sinnvoll an, wenn der RPi zum Beispiel openHAB
ausfuehrt (gibt es als runtime) und dazu ein openHAB binding fuer den
BS-Bus existiert (gibt es noch nicht). Falls es hier Java-Programmierer
gibt, koennen sie sich bemerkbar machen. Ich teile meinen noch nicht
ganz fertigen Code fuer ein openHAB 1 BS-Bus binding, weil ich die
Arbeit daran zur Zeit nicht fortsetzen kann.
Eine BS-Bus Steckplatine fuer den RPi brauchte nur die galvanische
Trennung und Pegelwandlung besorgen. Das wuerde auch Hardware bei der
Datenverbindung zum RPi sparen: das von der Heizung isolierte und auf
3.3V-Pegel umgesetzte BS-Bus-Signal koennte direkt (d.h. ohne die
zweifache Umsetzung auf RS232-Pegel und wieder zurueck auf 3.3V) an den
RPi weitergegeben werden.
Als Alternative zu openHAB gibt es wohl FHEM und dafür scheinbar die
Möglichkeit, Daten vom BSB abzufragen. Natürlich ist openHAB nicht FHEM.
Der RPi müsst dann die Kommunikation mit dem Bus übernehmen. Arduino
wäre dann raus aus der Nummer. Es gibt ja bereits anstelle von bsb_lan
die Software bsbgateway. Das ist ja bereits die Kommunikation mit der
Steuerung - allerdings nicht mit der speziellen Platine von freetz.
Die Platine von freetz war für mich die effizienteste Lösung (weil
verfügbar und ohne große Kenntnisse realisierbar). Die Schaltungen für
RPi mögen noch leichter realisierbar sein aber für den
Lötkolbenunkundigen nicht beherrschbar. Da müsste es auch mindestens
einen Bausatz dafür geben.
Wäre z.B. schön wenn sich bsb_lan und bsbgateway die bereits geleistete
Arbeit zu den bereits bekannten Telegrammen teilen würden. In bsb_lan
scheinen mehr Telegramme dekodiert zu sein als in bsb_gateway. In
Zukunft könnte das vielleicht aus einer Textdatei (Datenbank) gelesen
werden.
Am Ende sind es Projekte für interessierte Bastler, da Brötje bereits
mit Hardware und App für die Steuerung durch Endkunden wirbt (stand
letztens im Haustechnikdialog)
[quote]Wäre z.B. schön wenn sich bsb_lan und bsbgateway die bereits
geleistete Arbeit zu den bereits bekannten Telegrammen teilen
würden.[/quote]
Ich habe die Telegramme von bsbgateway schon im letzten Jahr mit denen
von bsb_lan in der Version 0.15 zusammengefuehrt. Seither habe ich
bsbgateway nicht mehr betrachtet.
[quote]In bsb_lan scheinen mehr Telegramme dekodiert zu sein als in
bsb_gateway.[/quote]
Es stimmt, die Aktivitaet bei bsb_lan ist hoeher als bei bsb_gateway und
hat zu einer hoeheren Abdeckung von beschriebenen Telegrammen gefuehrt.
[quote]In Zukunft könnte das vielleicht aus einer Textdatei (Datenbank)
gelesen werden.[/quote]
Fuer diesen Zweck habe ich als projekt- und implementierungsunabhaengige
Darstellung das XML-Format gewaehlt und mir ein Programm geschrieben,
das aus den bsb-lan C-Code sources automatisch eine XML-Datei erzeugen
kann. Im FHEM Forum findet sich die neueste XML-Datei, denn dort
geschieht der meiste Fortschritt. Wer will, kann diese Darstellung
unabhaengig vom Projekt als Grundlage nehmen. Hier im Forum steht ein
schon etwas aelteres Beispiel.
[quote]Die Platine von freetz war für mich die effizienteste Lösung
(weil
verfügbar und ohne große Kenntnisse realisierbar). Die Schaltungen für
RPi mögen noch leichter realisierbar sein aber für den
Lötkolbenunkundigen nicht beherrschbar. Da müsste es auch mindestens
einen Bausatz dafür geben.[/quote]
Wenn mich mein Gedaechtnis nicht taeuscht, erwartet bsbgateway die Daten
einfach an einem seriellen Computer-Interface. Eine Bus-Interface
Schaltung muesste also fuer Desktopcomputer neben galvanischer Trennung
und Pegelwandlung noch RS232 oder USB sprechen koennen. Das koennte beim
RasPi wie gesagt evtl. entfallen.
Ich hatte mir mein eigenes Businterface gebaut, das ueber RS232 und USB
mit einem Computer verbunden werden kann. Weiter oben ist meine
Schaltung abgebildet, die aber noch kleine Fehler enthaelt und daher
ueberholt ist. Ein Bausatz mit Platine waere dennoch ausschliesslich
fuer Hobbyisten geeignet, die wirklich gut mit dem Loetkolben umgehen
und mit diesem Werkzeug eine Platine mit SMD-Bauteilen bestuecken
koennen.
Sebastian Hilbert schrieb:> Am Ende sind es Projekte für interessierte Bastler, da Brötje bereits> mit Hardware und App für die Steuerung durch Endkunden wirbt (stand> letztens im Haustechnikdialog)
Bin mal gespannt, was das wird - mein Heizi hat mal bei Elco angefragt,
ob die Interesse hätten bzw. zumindest den OEM-Code rausgeben würden.
Die haben prompt abgesagt und sagten, die hätten kien Interesse, weil
"wir ab Herbst eine eigene App-Steuerung für die Siemensumgebung haben".
Bleibt die Frage, ob das dann einfach nur eine App für den OCI700 wird
(was ich am wahrscheinlichsten finde) oder ob die für den Enduser eine
(auch preislich?) abgespeckte Version herausgeben, mit der man dann
gerade mal so Sachen machen kann wie Wechsel zwischen Tag- und
Absenkmodus, Komfort- und Eco-Temperatur einstellen etc. Also in etwa so
wie bei der eq-3 Max! App.
Vermutlich reicht das für Otto-Normal-User auch, aber wer weiterhin
externe Temperatursensoren verwenden möchte oder Langzeit-Aufzeichnungen
von Werten machen möchte (insb. auch ohne Internet-Anbindung, wie jetzt
bei BSB_lan durch das Logging auf SD-Karte möglich ist), der wird
weiterhin auf diese Lösung setzen (müssen). Was schade ist, denn durch
die harten WEEE-Regelungen wird diese Lösung wohl leider nie über den
HomeBrew-Status hinaus kommen.
Gruß,
F.
Letztlich ist es betrüblich, dass die Heizungsprofis/bauer nicht mehr
auf den Zug aufspringen. So könnten Fehler schneller gefunden und
behoben werden.
Mir wurde kommuniziert, dass das Aufgabe des Werkskundendienstes sei.
Ich halte das Interesse der Hersteller für begrenzt was den Einsatz von
moderner (Langzeit)-Diagnosetechnik beim Endkunden angeht. Mal eben den
OCI700 anschließen, eine Momentaufnahme machen und den (eher wenig
aussagekräftigen) Fehlerspeicher auslesen, halte ich für nicht (in jedem
Fall) zielführend.
Als ich vor Jahren bei Elco angerufen habe, bezüglich Protokoll und
Internet - hatte ich eine ähnliche Absage erhalten. Steter Tropfen hölt
den Stein.
Der OEM Code herauszugeben wäre aber unverantwortlich, da es sich auch
Sicherheitsrelevante settings handeln könnte.
Ich persönlich würde gerne meine Heizung mit anderen vergleichen können.
Auch wäre eine Alarmierung bei Fehlern sinnvoll (Verwaltungen?)!
Die Möglichkeit einer "Remote" Beeinflussung der Therme erachte ich als
nice to have und sollte geblockt werden können.
Letzen Winter haben doch ein paar Bösewichte eine Heizungszentrale in
Skandinavien "abgestellt"
Würde jemand von euch seine Heizdaten gerne teilen ?
Hat jemand Fehlertelegramme in seine Datenfundus ?
gruss layerone
Rolf S. schrieb:> Als ich vor Jahren bei Elco angerufen habe, bezüglich Protokoll> und> Internet - hatte ich eine ähnliche Absage erhalten. Steter Tropfen hölt> den Stein.
Interessant...
> Der OEM Code herauszugeben wäre aber unverantwortlich, da es sich auch> Sicherheitsrelevante settings handeln könnte.
Klar, wenn da irgendwelche Möglichkeiten bestünden z.B. den Gasfluss
etc. zu verändern, dann sollte das natürlich nur in fachkundige Hände
gehen. Aber zumindest bei der Brötje (von der wir im BSB_lan Projekt
OEM-Parameter auslesen konnten) sind da auch unkritische Telegramme
dabei, die z.B. über den Brennerstatus genauere Auskunft geben etc.
> Ich persönlich würde gerne meine Heizung mit anderen vergleichen können.> Auch wäre eine Alarmierung bei Fehlern sinnvoll (Verwaltungen?)!
Wenn Du mit "Fehler" den Fehlerspeicher meinst, dann geht das mit
BSB_lan und wahrscheinlich auch mit BSBGateway.
> Die Möglichkeit einer "Remote" Beeinflussung der Therme erachte ich als> nice to have und sollte geblockt werden können.> Letzen Winter haben doch ein paar Bösewichte eine Heizungszentrale in> Skandinavien "abgestellt"
Aus dem Grund haben wir bei BSB_lan seit der vorletzten Version ein
Flag, das bei bedarf alle (oder ausgewählte) Parameter auf read-only
bzw. writeable setzt.
> Würde jemand von euch seine Heizdaten gerne teilen ?
Prinzipiell ja, nur ist die Vergleichbarkeit ja sehr von den
Witterungsbedingungen abhängig (das merke ich hier schon, wo ich nur
versuche, eine möglichst sinnvolle Korrelation zwischen Raum- und
Außentemperatur sowie Brennermodulation hinzubekommen). Vergleiche
zwischen verschiedenen Heizungssystemen oder gar Energieträgern wären
noch schwieriger.
> Hat jemand Fehlertelegramme in seine Datenfundus ?
Bis jetzt noch nicht, aber keine schlechte Idee...
Gruß,
F.
Hallo zusammen,
da wir "drüben" im FHEM-Forum mit der Entwicklung der BSB-Software
langsam das Gewünschte erreicht haben, geht mein Interesse jetzt doch
noch mal zum LPB-Bus über: Ich frage mich dabei besonders, wie der CRC
(vermutlich die letzten beiden Bytes) ermittelt wird, da XModem-16 hier
nicht greift, und auch die übrigen Checksummen auf lammertbies.nl nicht
zu passen scheinen. Ohne die CRC-Berechnung lassen sich aber die Daten
auf dem Bus ja bestenfalls mitlesen.
Ansonsten gibt es ja doch einiges an Ähnlichkeiten zwischen LPB und BSB,
was die Struktur angeht: Magic Bytes, Längenbytes, vier Byte lange
CommandIDs, ähnliche Codierung der Datenpakete (Temperaturen werden
durch 64 geteilt) etc.
Falls da also noch jemand eine Idee hat, dann freue ich mich über eine
Rückmeldung, gerne auch direkt im FHEM-Thread:
https://forum.fhem.de/index.php/topic,29762.0.html
Gruß,
F.
Ok, diese Form der Prüfsumme habe ich so noch nicht gesehen, aber
nachdem mir aufgefallen ist, dass sich bei ähnlichen Zeilen, die nur um
wenige Zähler abweichen, auch die Prüfsumme nur um genau diese Zähler
abweicht, konnte es sich nicht um CRCs handeln. Als ich dann per Script
die Summe der Werte von den Prüfsummen abgezogen habe, bin ich zwar
nicht für jede Zeile, aber für jede Zeile einer bestimmten Länge auf das
gleiche Ergebnis gekommen.
Wenn man dann annimmt, dass alle Bytes (außer Prüfsumme) Nullen wären,
kommt man auf folgendes Muster für die Basis:
15 Byte Länge: F1 0E
16 Byte Länge: F0 0F
17 Byte Länge: EF 10
18 Byte Länge: EE 11
D.h., das erste Byte nimmt ab und das zweite nimmt zu, wenn die
Zeilenlänge größer wird. Beide zusammen ergeben dann eine 16-Bit Zahl,
auf die dann die Summe aller Telegramm-Bytes (außer Prüfsumme natürlich)
hinzuaddiert wird. Die Grundlage beider Bytes scheint die Telegrammlänge
(wieder ohne PS) zu sein, einmal von FF subtrahiert, einmal "plain",
aber die Telegrammlänge jeweils von Null an gezählt, also letztlich um
eins reduziert.
Die Formel scheint von daher zu sein:
(255 - (Telegrammlänge ohne PS - 1)) * 256 + Telegrammlänge ohne PS - 1
+ Summe aller Telegrammbytes
Damit wäre es dann zumindest auch möglich, Telegramme wie z.B.
Raumtemperatur etc. auf den LPB-Bus zu schicken, wenn die entsprechenden
CommandIDs sowie die Sender- und Empfänger-Codierungen entschlüsselt
sind...
Gruß,
F.
So, inzwischen ist die Entschlüsselung des LPB-Protokolls (fast)
abgeschlossen und eine rudimentäre Abfragefunktion in das
BSB-Lan-Projekt integriert worden, alle Infos zum Protokoll habe ich
hier einmal aufgeschrieben:
https://forum.fhem.de/index.php/topic,29762.msg677114.html#msg677114
Was mir jetzt fehlt, weil ich keine Steuer-/Regelungsgeräte für den
LPB-Bus habe, ist jemand, der entsprechende Abfragen über den Bus
schicken und gleichzeitig auf die CommandIDs lauschen kann. Ein paar
konnte ich durch eigene Versuche und aus den Mitschnitten hier im Thread
schon herausfinden, sie sind ebenfalls in dem verlinkten Beitrag
gesammelt. Wichtig wären die CommandIDs zu Komfort- und
Reduzierttemperatur, Betriebsmodus und Raumfühlertemperatur. Damit ließe
sich ein LPB-System dann schon sehr gut steuern...
Gruß,
F.
Hallo zusammen,
da es hier ja auch zu Beginn um den LPB-Bus ging und einige Besitzer
älterer Thermen vielleicht daran interessiert sein könnten: BSB-LAN, das
"drüben" im FHEM-Forum entwickelt wurde, hat nach der Entschlüsselung
des Protokolls nun quasi auch den kompletten LPB-Befehlssatz mit an
Bord, so dass Programm und Platine transparent an beiden Bus-Systemen
eingesetzt werden können. Falls Michales Platine schon weg sein sollte:
Wir starten auch demnächst wieder eine Sammelbestellung. Mehr Infos
unter diesen beiden Links:
https://forum.fhem.de/index.php/topic,29762.msg682638.html#msg682638https://github.com/fredlcore/bsb_lan
Gruß,
F.
So, nach einiger Zeit der Planung und des Bugfixings gibt es nun dank
der Hilfe von Johannes Löhnert eine neue Version der Adapter-Platine.
Diese hat für den Arduino die gleiche Funktion wie vorher, kann aber nun
über eine Buchsenleiste auch an einem Raspberry Pi betrieben werden, und
zwar mit der bsb_gateway Software von Johannes
(https://github.com/loehnertj/bsbgateway). Die Software hat zwar nicht
die umfangreiche Parameter-Anzahl wie BSB_Lan, aber die Grundfunktionen
sind auch dort vorhanden, und wer schon einen Pi bei sich zu Hause
liegen hat, für den ist das vielleicht eine interessante Alternative
(bei mir hat es seltsamerweise beim Pi 3 Aussetzer gegeben, beim Pi 2
lief alles problemlos, aber vielleicht sind die seriellen Pins des Pi 3
bei mir auch nicht ganz in Ordnung).
Man muss sich beim Zusammenbauen allerdings zwischen einer der beiden
Einsatzmöglichkeiten entscheiden, denn der Pi hat als Anschluss ja
Stiftleisten, während der Arduino Buchsenleisten hat. Beide
Anschlussmöglichkeiten gleichzeitig einzubauen, käme sich also in die
Quere. Für einen Wechsel müsste man also die jeweilige andere Variante
wieder auslöten.
Ich würde auch dafür wieder eine Sammelbestellung organisieren,
Interessenten können sich am besten per Mail an bsb (ät) code-it.de
melden. Support kann ich für Johannes' Software allerdings nicht bieten,
da müsste man sich dann direkt mit ihm in Verbindung setzen. Mein Fokus
wird weiterhin auf BSB_lan liegen, Support dafür gibt's im FHEM-Forum:
https://forum.fhem.de/index.php?topic=29762.new;topicseen#new
Gruß,
F.
Und weil hier ja auch versucht wurde, den PPS-Bus zu entschlüsseln: Wir
sind "drüben" im FHEM-Thread nun hoffentlich zu einer Lösung gekommen,
die dieses System, das von der Hardwareübertragung her identisch mit BSB
und LPB ist, nun auch in seinem deutlich reduziertem Funktionsumfang
nutzbar macht und somit u.U. eine QAA50 bzw. QAA70 ersetzen kann:
https://forum.fhem.de/index.php/topic,29762.msg736615.html#msg736615
Viele Grüße
F.
Hallo,
Ich habe meine alte Heinzung (mit QAA50 alt version) automatisiert.
Ich kann von meiner Wohnung, die Heizung meines zweiten Hauses
einschalten.
Ich benutze einen STM32F7 mit Chibios und MbedTLS.
Es war sehr schwierig, weil der QAA50 gar nicht wie der QAA70
funktioniert.
Ohne diesen Thread hätte ich es nie getan.
Das Schema von "bsb_lan" funktionierte gar nicht mit meiner Heizung.
(Übertragungsrate zu niedrig, Logikpegel abhängig von der Leistung,
falsche Übertragungspolarität, linear-Opto-Isolatoren zu schwach)
Ich benutzte die Idee von "brha": ein 1W 5VDC/5VDC mit isolation.
So könnte ich meine MOSFETs und logik-Opto-Isolatoren polarisieren, auch
when der 12V nicht vom PPS kommt.
Vielen dank,
Simon
Hello,
The QAA50 room unit use the 12V PPS bus to communicate with my heater.
As it differs significantly from QAA70, I'll post here my observations:
(Message formatting, CRC etc. is already discussed inside this thread.)
The protocol is serial 4800bit/s, 1startbit, 8databits, 1odd parity bit,
2stopbits.
Heater messages (loop from 1 to 4):
1) 0x1D48FFFFFFFFFFXXCC: ?
always 0x00
2) 0x1D4DFFFFFFFFFFXXCC: Burner
0x0D = burner not active
0x07 = burner active
3) 0x1D4FFFFFFFFFFFXXCC: Room device
0x00 = room device present
0x01 = no room device
4) 0x1D4CFFFFFFFFFFXXCC: Comfort mode
0x00 = economy
0x01 = comfort
QAA50 messages (loop from 1 to 6):
1) 0xFD38FFFFFFFFFFXXCC: Room device type
0x52 = QAA50
2) 0xFD4EFFFFFFFFFFXXCC: ?
always 0x00
3) 0xFD49FFFFFFFFFFXXCC: Heater mode
0x00: automatic
0x01: manual
0x02: standby
4) 0xFD55FFFFFFFFFFXXCC: ?
always 0x03
5) 0xFD18FFFFFFFFXXXXCC: temperature setting potentiometer
min -3°C: 0xFF54 = -172, this is int16_t
middle 0°C: 0x0004 = 4
max +3°C: 0x00BC = 188
6) 0xFD28FFFFFFFFXXXXCC: room temperature * 64
20°C = 0x0500
QAA50 Special messages:
0xFB4CFFFFFFFFFFXXCC: comfort mode set
0x00 = economy
0x01 = comfort
0xFE4CFFFFFFFFFFXXCC: comfort mode validate
always 0xFF
When the heater is started, the bus will come at 12V. Then the heater
will pull the bus to 0V for a short time. When it goes back to 12V, the
heater will search for a room device. The heater will alternatively send
a message 0x1D.... and a request 0x17 with about 0.5s beetween the two.
The room device must send its message about 1ms after the 0x17 from the
heater.
When the room device is not paired with the heater, it must start by
sending 0xFD38... after the 0x17 that follows a 0x1D48... It is the only
way to pair the room device to my heater. (My heater displays override
when the room device is paired) After this, the room device can answer
to 0x17 with messages from its loop.
To toggle the comfort mode of the heater, the room device must answer
0xFB4C... to a 0x17. the heater will send 0x17 again, the room device
must send 0xFE4C... The heater will then send it's updated setting
0x1D4C...
I used two relays so the the room device is normally connected. I can
remotely switch the room device away, and switch my MCU on the PPS bus.
I wait until my heater pull the bus low for a short time and start
searching for a room device. Once it is done, my MCU start acting like
it is the room device (using BME280 temperature sensor). It is a very
easy way to remotely control the heater.
Best regards,
Simon
Hm, ich sehe nicht, wo das QAA50-Protokoll anders als das
QAA70-Protokoll sein soll. Bis auf die "QAA50 Special Message" sind alle
(und weitere) Telegramme auch auf der QAA70 existent und so in BSB-LAN
eingepflegt (suche mal im Quellcode von BSB_lan.ino nach "PPS-Bus
handling"). Bei der Komfortmodus-Nachricht werde ich mal schauen, ob die
auch bei der QAA70 vorkommt.
Hardwaremäßig ist das, was Du beschreibst, ebenfalls mit
QAA70-PPS/BSB/LPB identisch, insofern ist mir nicht ganz klsr, worin die
"signifikanten" Unterschiede liegen sollen.
Was den Aufbau des Interfaces angeht, ist das natürlich eine
Herangehensfrage. Es wundert mich nur insofern, dass das BSB-LAN-Schema
bei Dir nicht läuft, als dass es von der Hardware keinen mir bekannten
Unterschied gibt (was sich m.E. auch an den identischen
Übertragungsparametern zeigt). Aber wenn es bei Dir so geklappt hat, ist
das ja die Hauptsache.
Der protocol ist nicht sehr unterschiedlich. Der BSB_lan.ino und der
ppsmon.py haben mir gut geholfen zu beginnen.
Es gibt verschiedene QAA50 Versionen. Ich habe den Ältesten, der aussen
keine Display und keine Markierung hat.
Meine Heizung (1996) erkennt das Gerät nur, wenn das message 0x38 zur
richtigen Zeit ankommt (nur nach ein 0x48).
Meine Heizung kennt nicht die Nachrichten von QAA70. Es ist möglich,
dass der QAA70 später verfügbar war.
Falls ich eine bestimmte QAA70-Nachricht sende, wird mein Heizgerät
verrückt. Später antwortet es eine Nachricht ohne 0x1D wie
0x48FFFFFFFFFFXXCC... Mein Gerät ist immer noch verbunden (override auf
Heizung display). Meine Heizung ist dann ein wenig gestört. Obwohl der
Gerät verbunden ist, kann es nicht mehr Heizung-parameters wie Comfort
ändern.
Aus materieller Sicht, mit 4N25 und darligton war es zu schwach um mein
heizung bus nach 0V zu ziehen. Beim Veränderung des basis-Widerstande,
geht es besser unter 5V, aber mit einem schreckliches Aussehen.
Ich hatte der Arduino bsb_lan version für TX verwendet. Ich sah nicht
gut aus, dass es zieht der PPS bus nach 0V mit 5V TX Ruhezustand :)
Ich denke, dass alle Probleme auf die Tatsache zurückzuführen sind, dass
meine Heizung und Gerät alt sind.
Simon
Danke für die Rückmeldung, PPS scheint wirklich das am wenigsten
standardisierte Protokoll der drei (BSB, LPB, PPS) zu sein...
Allerdings ist es auch bei der QAA70 so, dass auf die 0x48 mit einer
0x38 geantwortet werden muss - und das sehr schnell (wenige
Millisekunden). Das hat mir bei der Analyse des Protokolls echt graue
Haare wachsen lassen, weil ich die Daten zwischen QAA und Heizung immer
1:1 übernommen hatte, aber durch Debug-Meldungen das Timing nicht mehr
stimmte.
Vielleicht spielt dabei aber auch die zugrundeliegende Hardware eine
Rolle, das will ich nicht ausschließen.
Interessant wäre, ob die anderen Telegramme, die in BSB-LAN hinterlegt
sind, auch bei Deiner Therme funktionieren (Außentemperatur,
Vorlauftemperatur, Wochentag etc.). Auch da scheint es von Therme zu
Therme Unterschiede bei der PPS-Implementierung zu geben - allerdings
mit dem Problem, dass mir - anders als bei BSB/LPB - noch nicht klar
ist, wie die QAA50/70 die Therme eindeutig identifizieren, um dann die
entsprechenden Protokolle zu schicken. Über 0x38 identifiziert sich ja
nur das Raumgerät als QAA50 oder QAA70, aber wie die Therme das macht,
ist mir bis jetzt noch nicht klar...
Wie es aussieht, haben neuere und "einfachere" Thermen von Brötje jetzt
statt BSB einen sogenannten "R-Bus", an den sich auch das neue
WLAN-fähige Raumgerät "IDA" anschließen lässt. Ich habe diesen Bus mal
etwas analysiert, der aber leider völlig inkompatibel zu allem ist, was
wir hier herausgefunden haben. Die Infos habe ich daher in einem neuen
Thread zusammengestellt:
Beitrag "Neuer Bus bei einigen Brötje Heizungen: R-Bus"
Thread beobachten
Seitenaufteilung abschalten
