Announcement: there is an English version of this forum on 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
Angehängte Dateien:
-
PW201501251429.png
3,6 KB -
HT201501251429.png
5,4 KB
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Angehängte Dateien:
-
20151106_220343.jpg
210 KB -
bsb-linkv0.1-Schema.jpg
100 KB
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
vielen Dank für die Info! Ich werde mich mal umschauen und meine Ergebnisse posten, falls es jemanden überhaupt interessiert.
PS Hat jemand von euch vielleicht zum PPS Interface / Protokoll Unterlagen?
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
Angehängte Dateien:
-
LPBInterfaceSchematic.png
100 KB -
LPBInterface.JPG
260 KB
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
Angehängte Dateien:
-
Raspi-DB9cs.JPG
140 KB
[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.
In dem oben im Forum zum Download angebotenen "Systemhandbuch SSR Plus" werden in einer Tabelle verschiedene Geräte genannt: SSR, BSW, BLW, BCA, ZR1/2 und Kessel L,TE und SOB. SSR = Solar- und Systemregler BSW = Sole/Wasser Wärmepumpe BLW = Luft/Wasser Wärmepumpe BCA = Heizungsregler für Heizkreis-, Trinkwasser- und Kaskadenfunktion SOB = Öl Brennwertkessel, Standgerät? Im Gegensatz zu WOB = Öl Brennwertkessel, Wandgerät? Diese und weitere Geräte lassen sich außerdem anhand eines Projekterfassungsblatts identifizieren: https://www.broetje.de/cps/rde/xbcr/broetje_de/DOCUMENTS/Produkte_Formulare_FHW_GH/BROETJE_Projekterfassungsbogen.pdf Bei Broetje gibt es unter https://www.broetje.de/cps/rde/xbcr/broetje_de/DOCUMENTS/Produkte_Broschueren_FH/Broschuere_Regelung_ISR_App.pdf eine Broschüre, in der diese Komponenten kurz erklärt sind.
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.
Ich liebe Codeknacken :-) Anhand der vielen ff-Werte ist anzunehmen dass die Bits wie auch beim BSB invertiert werden müssen. Die invertierten Telegramme sehen so aus (schon mit suggestiven Lücken): 78 13 ff 00 fc 02 00 14 02 15 00 02 0a 00 01 00 00 fa f1 cb 78 0e 00 04 c0 02 00 14 86 05 05 00 64 f5 60 78 18 04 00 0c 02 00 14 87 05 05 00 64 00 5a 00 ef 03 f7 00 00 a2 d0 ee 76 78 0e 01 04 c0 02 00 14 a6 05 05 00 64 f5 81 78 18 04 01 0c 02 00 14 a7 05 05 00 64 00 8a 00 64 03 e8 00 00 79 b6 ed ea 78 11 f0 00 fc 02 00 14 02 19 00 01 fd 00 08 03 f3 be 78 11 ff 00 fc 02 00 14 02 19 19 01 fe 00 08 03 f3 e7 Durch Vergleich der Telegramme und zusammen mit dem was wir über den BSB wissen, würde ich folgendes vermuten: (Bsp. letztes Telegram) 78 = magic byte 11 = Länge (ohne das Magic byte) beachte 0x11 = 17 -- stimmt nachprüfbar! -> bestätigt das Invertieren. ff = Zieladresse? (ff=Broadcast) 00 = Quelladresse? (00 = Hauptgerät?) - würde passen wenn Telegramme 2-5 dasselbe Feld von 2 Geräten abgefragt haben. 02 00 14 02 = ??? 19 19 01 fe = Feld-ID (beachte insb. die beiden Challenge-Response-Telegramme) 00 08 03 = Wert f3 e7 = CRC Gruß Johannes
:
Bearbeitet durch User
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
layerone schrieb: > Punkt 3:Verrate uns doch mal was für eine Steuerung bei dir eingebaut > ist. Eine ISR-SSR (siehe oben) > Dazu gibt es auch wohl auch Doks wo beschrieben ist auf welcher > Klemme welche funktion zu finden ist. Klemme? Funktion? Ich weiß exakt, an welcher Klemme welcher Sensor oder Aktor angeschlossen ist. Welchen Zusammenhang Sie mit den Daten auf dem Bus sehen, können Sie ja noch erklären. > Du wirst schnell festellen, dass man sehr viele möglichkeiten hat. > Auch wäre es interessant, das LPB addressierungschem deiner Anlage zu > kennen. Hier ist es * ================================================================ * FM-K GSM Fernwartungs-Interface OCI611 * Bezeichnung: Zentrale * LPB-Adresse Zentrale Segment 0 Gerät 5 * ================================================================ * ISR-SSR C Solarsystem-Regler * Bezeichnung: Regler * LPB-Adresse Regler Segment 0 Gerät 1 * ================================================================ * Kesselregler * Modell RVS... * Bezeichnung: Regler * LPB-Adresse Regler Segment 0 Gerät 2 * ================================================================ Alle drei hängen am Bus, aber das OCI611 bleibt hier jetzt unbeachtet. Ich verbinde ein OCI700 mit dem LPB-Bus socket im ISR-SSR und schleife mein Bus-Interface in diese Verbindungsleitung ein. Es protokolliert rein passiv, was auf dem Bus vorgeht und was zwischen OCI700 und der Anlage hin- und her geht. Der OCI Adapter ist mit einem Laptop verbunden, auf dem das (Fern-)Konfigurationsprogramm für solche Anlagen läuft. > > Versuch doch mal einzelne Telegramme einer bestimmten ServiceTool Zeile > zuzuweisen und hier zu posten. Als Beispiel habe ich das Menü "Uhrzeit" mit nur drei Datenpunkten genommen. Die Adressen ersieht man wie folgt: Im Menue "Uhrzeit" werden hier drei Datenpunkte abgefragt: Adresse Datenpunktname Wert Regler;0;1 Uhrzeit (sollte mit dem Sniffer ungefaehr korrelieren) Regler;0;1 Sommerzeitbeginn ----, 25.März ---- Regler;0;1 Sommerzeitende ----, 25.Oktober ---- Wenn alle drei Datenpunkte abgefragt worden sind, liefert der Sniffer weiterhin laufend Daten; offensichtlich arbeitet das PC-Programm in einer Schleife, um die drei Datenpunkte im Menü aktuell zu halten. Das selbe Vehalten zeigt das Programm übrigens auch in allen anderen Menüs. Der Übersichtlichkeit halber habe ich alle Zeitangaben bei den ersten Zeilen in der Liste entfernt und sie untereinander gestellt. Telegramme auf dem Bus separiere ich in dieser Analyse, wenn die Zeit zwischen zwei Bytes länger als 1.15 character times ist. Später folgen in der Liste noch ein paar Zeilen, die repräsentativ zeigen, welche Angaben mein Analyseprogramm für jedes Telegramm aus den Snifferdaten zieht. Falls die letzten beiden Bytes der CRC sein sollten, werden sie jedenfalls nicht nach dem in diesem Forum bisher berichteten Verfahren berechnet, wie man sieht. ---------------------------------------------------- inFile is: 20160322-Bedienbuch-Dev1-Uhrzeit.dat outFile is: 20160322-Bedienbuch-Dev1-Uhrzeit-sep.txt The input file contains 2471 data and RS232 control signal records. Disregard all records with RS232 control signals. Disect the byte stream if a pause is longer than 2635 us (1.15 character time). Data are shown inverted. Data collection start time: 2016-03-22 13:04:57.674999 First data record time: 2016-03-22 13:05:28.797001 ---------------------------------------------------- 78 0e 00 08 c0 02 00 14 66 05 21 04 ab f5 ab 78 10 08 00 0c 02 00 14 67 21 05 04 ab 00 28 f3 24 78 0e 00 08 c0 02 00 14 86 05 21 04 aa f5 ca 78 10 08 00 0c 02 00 14 87 21 05 04 aa 00 64 f3 7f 78 0e 00 08 c0 02 00 14 a6 05 05 07 be f5 e5 78 10 08 00 0c 02 00 14 a7 05 05 07 be 00 01 f3 37 78 0e 00 08 c0 02 00 14 c6 05 2d 05 74 f5 e1 78 10 08 00 0c 02 00 14 c7 2d 05 05 74 00 01 f3 33 78 0e 00 08 c0 02 00 14 e6 05 2d 05 8e f6 1b 78 11 08 00 0c 02 00 14 e7 2d 05 05 8e 00 05 60 f2 d3 78 0e 00 08 c0 02 00 14 06 05 2d 05 90 f5 3d 78 11 08 00 0c 02 00 14 07 2d 05 05 90 00 04 80 f2 14 78 0e 00 08 c0 02 00 14 26 05 2d 05 92 f5 5f 78 11 08 00 0c 02 00 14 27 2d 05 05 92 00 02 80 f2 34 78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb 78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 2d 00 eb f6 78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 23 78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 49 78 11 ff 00 cc 02 00 14 02 15 00 02 2d 00 0d 30 f2 fc 78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b 78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 2e 00 ec 57 78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 83 78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 a9 78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b 78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 2e 00 eb b7 78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 e3 78 0e 00 08 c0 02 00 14 46 05 05 04 b2 f5 76 78 17 08 00 0c 02 00 14 47 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 09 78 0e 00 08 c0 02 00 14 66 05 05 00 0b f4 eb 78 17 08 00 0c 02 00 14 67 05 05 00 0b 00 74 03 16 02 0d 03 2f 00 ec 18 78 0e 00 08 c0 02 00 14 86 05 05 04 b3 f5 b7 78 17 08 00 0c 02 00 14 87 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 43 78 0e 00 08 c0 02 00 14 a6 05 05 04 b2 f5 d6 78 17 08 00 0c 02 00 14 a7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 69 78 0e 00 08 c0 02 00 14 c6 05 05 00 0b f5 4b 78 17 08 00 0c 02 00 14 c7 05 05 00 0b 00 74 03 16 02 0d 03 30 00 ec 79 78 0e 00 08 c0 02 00 14 e6 05 05 04 b3 f6 17 78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 a3 78 0e 00 08 c0 02 00 14 06 05 05 04 b2 f5 36 78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0 c9 78 0e 00 08 c0 02 00 14 26 05 05 00 0b f4 ab 78 17 08 00 0c 02 00 14 27 05 05 00 0b 00 74 03 16 02 0d 03 31 00 eb da 78 0e 00 08 c0 02 00 14 46 05 05 04 b3 f5 77 78 17 08 00 0c 02 00 14 47 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 03 78 0e 00 08 c0 02 00 14 66 05 05 04 b2 f5 96 78 17 08 00 0c 02 00 14 67 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 29 78 0e 00 08 c0 02 00 14 86 05 05 00 0b f5 0b 78 17 08 00 0c 02 00 14 87 05 05 00 0b 00 74 03 16 02 0d 03 31 00 ec 3a 78 0e 00 08 c0 02 00 14 a6 05 05 04 b3 f5 d7 78 17 08 00 0c 02 00 14 a7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 63 78 0e 00 08 c0 02 00 14 c6 05 05 04 b2 f5 f6 78 17 08 00 0c 02 00 14 c7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 89 78 0e 00 08 c0 02 00 14 e6 05 05 00 0b f5 6b 78 17 08 00 0c 02 00 14 e7 05 05 00 0b 00 74 03 16 02 0d 03 32 00 ec 9b 78 0e 00 08 c0 02 00 14 06 05 05 04 b3 f5 37 78 17 08 00 0c 02 00 14 07 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 c3 78 0e 00 08 c0 02 00 14 26 05 05 04 b2 f5 56 78 17 08 00 0c 02 00 14 27 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0 e9 78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb 78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 33 00 eb fc 78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 23 78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 49 78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b 78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 33 00 ec 5c 78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 83 78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 a9 78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b 78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 34 00 eb bd 78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 e3 ........ 78 0e 00 08 c0 02 00 14 46 05 05 04 b2 f5 76 78 17 08 00 0c 02 00 14 47 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 09 ........ 78 0e 00 08 c0 02 00 14 66 05 05 00 0b f4 eb 78 17 08 00 0c 02 00 14 67 05 05 00 0b 00 74 03 16 02 0d 03 35 00 ec 1e ....5... 78 0e 00 08 c0 02 00 14 86 05 05 04 b3 f5 b7 78 17 08 00 0c 02 00 14 87 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 43 .......C 78 0e 00 08 c0 02 00 14 a6 05 05 04 b2 f5 d6 78 17 08 00 0c 02 00 14 a7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 69 .......i 78 0e 00 08 c0 02 00 14 c6 05 05 00 0b f5 4b 78 17 08 00 0c 02 00 14 c7 05 05 00 0b 00 74 03 16 02 0d 03 36 00 ec 7f ....6... 78 0e 00 08 c0 02 00 14 e6 05 05 04 b3 f6 17 x.............. Block length=15 (0x0f) bytes. CCITT-XMODEM CRC over bytes [:-2] is 0xB923 Pause of 25,915us at 885,872,216 us (+10,591,996 us offset): 78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 x............... 19 ff ff ff ff 16 f1 a3 ........ Block length=24 (0x18) bytes. CCITT-XMODEM CRC over bytes [:-2] is 0x545E Pause of 119,119us at 886,044,038 us (+10,763,818 us offset): 78 0e 00 08 c0 02 00 14 06 05 05 04 b2 f5 36 x.............6 Block length=15 (0x0f) bytes. CCITT-XMODEM CRC over bytes [:-2] is 0x920E Pause of 24,535us at 886,100,648 us (+10,820,428 us offset): 78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a x............... 19 ff ff ff ff 16 f0 c9 ........ Block length=24 (0x18) bytes. CCITT-XMODEM CRC over bytes [:-2] is 0xF1D9
Angehängte Dateien:
-
ISR-SSR-etwasgenauer.jpg
190 KB -
hydrschema.jpg
110 KB
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 ;-)
Noch zwei Zitate aus der Brötje-Dokumentation zum ISR-SSR C und den
Buses:
"Kesselkaskadenfunktion für bis zu 16 Kessel in Verbindung mit ISR-Plus
oder LPB-Bus-fähiger EuroControl Regelung, (..) Kommunikationsfähig mit
ISR-Plus, LPB-Bus-fähigen EuroControl Reglern und über CIB oder BM mit
dem SGB/WGB."
"Notwendiges zusätzliches Zubehör bei Pro EVO-Geräten: Clip-in Busmodul
CIB C
Notwendiges zusätzliches Zubehör bei LPB-Bus-fähigen
Gas-Brennwertgeräten Serie E sowie NovoCondens WOB: Clip-in Busmodul BM"
Anmerkung: In den mir vorliegenden Dokumentationen sind die Brötje
Kessel über den LP-Bus mit anderen Anlagenkomponenten verbunden.
================
Die Daten auf dem LP-Bus habe ich ansatzweise analysiert. Für diese
Analyse habe ich Daten im Menü 'Datum und Uhrzeit'verwendet, wie sie das
OCI700 Service Tool mit der Anlage austauscht. Dieses Menü enthält nur
drei Datenpunkte, weswegen sich der Analyseaufwand in Grenzen hält. Das
OCI700 ist an einem Windows PC angeschlossen, in dem das
Konfigurationsprogramm ACS läuft.
Wie schon in einem anderen Beitrag erwähnt, sendet das ACS-Programm
laufend Anfragen an die Anlage, die darauf antwortet. Bei der
beschriebenen Analyse stellt sich heraus, dass es acht verschiedene (!)
Anfragen zu jedem der drei Datenpunkte gibt gibt. Jeder Anfrage ist
genau eine von acht ebenfalls unterschiedlichen Antworten zugeordnet.
Hier ein Mitschrieb; man sieht sehr schnell, dass der Aufbau der
Anfragen und Antworten sich von denen auf dem BS-Bus unterscheidet.
----------------------------------------------------
inFile is: 20160322-Bedienbuch-Dev1-Uhrzeit.dat
outFile is: 20160322-Bedienbuch-Dev1-Uhrzeit-sep2.txt
The input file contains 2471 data and RS232 control signal records.
Disregard all records with RS232 control signals.
Disect the byte stream if a pause is longer than 2635 us (1.15 character
time).
Data are shown inverted.
Data collection start time: 2016-03-22 13:04:57.674999
First data record time: 2016-03-22 13:05:28.797001
----------------------------------------------------
DCE starts at 875,280,220 us (+0 us offset) with:
U 78 0e 00 08 c0 02 00 14 66 05 21 04 ab f5 ab
U 78 10 08 00 0c 02 00 14 67 21 05 04 ab 00 28 f3 24
U 78 0e 00 08 c0 02 00 14 86 05 21 04 aa f5 ca
U 78 10 08 00 0c 02 00 14 87 21 05 04 aa 00 64 f3 7f
U 78 0e 00 08 c0 02 00 14 a6 05 05 07 be f5 e5
U 78 10 08 00 0c 02 00 14 a7 05 05 07 be 00 01 f3 37
U 78 0e 00 08 c0 02 00 14 c6 05 2d 05 74 f5 e1
U 78 10 08 00 0c 02 00 14 c7 2d 05 05 74 00 01 f3 33
U 78 0e 00 08 c0 02 00 14 e6 05 2d 05 8e f6 1b
U 78 11 08 00 0c 02 00 14 e7 2d 05 05 8e 00 05 60 f2 d3
U 78 0e 00 08 c0 02 00 14 06 05 2d 05 90 f5 3d
U 78 11 08 00 0c 02 00 14 07 2d 05 05 90 00 04 80 f2 14
U 78 0e 00 08 c0 02 00 14 26 05 2d 05 92 f5 5f
U 78 11 08 00 0c 02 00 14 27 2d 05 05 92 00 02 80 f2 34
Bis hierher schreibe ich anscheinend unsolicited Bustelegramme mit.
Anmerkung: U = unique.
Ab hier sind die Anfragen des Programms und Antworten der Anlage
identifizierbar.
Es gibt acht verschiedene Anfragen A..H fuer "Begin Standard Time",
"Begin Daylight-Saving Time" und fuer "Date & Time".
Es gibt ebenso acht verschiedene Antworten A..H auf "Begin Standard
Time"
und "Begin Daylight-Saving Time". Anfrage und Antwort sind Paare.
Die Antworten auf "Request Date & Time" hingegen sind einzigartig
(U = unique).
Gelegentlich funkt in die Programm <-> Anlagenkommunikation
noch ein Bustelegramm dazwischen (???Bus???).
A 78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb REQ date & time
U 78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 2d 00 eb
f6
| | | | | | |
Len | | 22 | | 46s
| Mar | 3min
1900+116 13h
A 78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 REQ Begin
Daylight-Saving Time
A 78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
23
| | |
Len | 25
Mar
A 78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 REQ Begin std time
A 78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
49
| | |
Len | 25
Okt
78 11 ff 00 cc 02 00 14 02 15 00 02 2d 00 0d 30 f2 fc ???Bus???
B 78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b REQ date & time
U 78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 2e 00 ec
57
B 78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 REQ Begin
Daylight-Saving Time
B 78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
83
B 78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 REQ Begin std time
B 78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
a9
C 78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b REQ date & time
U 78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 2e 00 eb
b7
C 78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 REQ Begin
Daylight-Saving Time
C 78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0
e3
C 78 0e 00 08 c0 02 00 14 46 05 05 04 b2 f5 76 REQ Begin std time
C 78 17 08 00 0c 02 00 14 47 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
09
D 78 0e 00 08 c0 02 00 14 66 05 05 00 0b f4 eb REQ date & time
U 78 17 08 00 0c 02 00 14 67 05 05 00 0b 00 74 03 16 02 0d 03 2f 00 ec
18
D 78 0e 00 08 c0 02 00 14 86 05 05 04 b3 f5 b7 REQ Begin
Daylight-Saving Time
D 78 17 08 00 0c 02 00 14 87 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
43
D 78 0e 00 08 c0 02 00 14 a6 05 05 04 b2 f5 d6 REQ Begin std time
D 78 17 08 00 0c 02 00 14 a7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
69
E 78 0e 00 08 c0 02 00 14 c6 05 05 00 0b f5 4b REQ date & time
U 78 17 08 00 0c 02 00 14 c7 05 05 00 0b 00 74 03 16 02 0d 03 30 00 ec
79
E 78 0e 00 08 c0 02 00 14 e6 05 05 04 b3 f6 17 REQ Begin
Daylight-Saving Time
E 78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
a3
E 78 0e 00 08 c0 02 00 14 06 05 05 04 b2 f5 36 REQ Begin std time
E 78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0
c9
F 78 0e 00 08 c0 02 00 14 26 05 05 00 0b f4 ab REQ date & time
U 78 17 08 00 0c 02 00 14 27 05 05 00 0b 00 74 03 16 02 0d 03 31 00 eb
da
F 78 0e 00 08 c0 02 00 14 46 05 05 04 b3 f5 77 REQ Begin
Daylight-Saving Time
F 78 17 08 00 0c 02 00 14 47 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
03
F 78 0e 00 08 c0 02 00 14 66 05 05 04 b2 f5 96 REQ Begin std time
F 78 17 08 00 0c 02 00 14 67 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
29
G 78 0e 00 08 c0 02 00 14 86 05 05 00 0b f5 0b REQ date & time
U 78 17 08 00 0c 02 00 14 87 05 05 00 0b 00 74 03 16 02 0d 03 31 00 ec
3a
G 78 0e 00 08 c0 02 00 14 a6 05 05 04 b3 f5 d7 REQ Begin
Daylight-Saving Time
G 78 17 08 00 0c 02 00 14 a7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
63
G 78 0e 00 08 c0 02 00 14 c6 05 05 04 b2 f5 f6 REQ Begin std time
G 78 17 08 00 0c 02 00 14 c7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
89
H 78 0e 00 08 c0 02 00 14 e6 05 05 00 0b f5 6b REQ date & time
U 78 17 08 00 0c 02 00 14 e7 05 05 00 0b 00 74 03 16 02 0d 03 32 00 ec
9b
H 78 0e 00 08 c0 02 00 14 06 05 05 04 b3 f5 37 REQ Begin
Daylight-Saving Time
H 78 17 08 00 0c 02 00 14 07 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0
c3
H 78 0e 00 08 c0 02 00 14 26 05 05 04 b2 f5 56 REQ Begin std time
H 78 17 08 00 0c 02 00 14 27 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0
e9
A 78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb REQ date & time
U 78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 33 00 eb
fc
A 78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 REQ Begin
Daylight-Saving Time
A 78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
23
A 78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 REQ Begin std time
A 78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
49
B 78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b REQ date & time
U 78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 33 00 ec
5c
B 78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 REQ Begin
Daylight-Saving Time
B 78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
83
B 78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 REQ Begin std time
B 78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
a9
C 78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b REQ date & time
U 78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 34 00 eb
bd
C 78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 REQ Begin
Daylight-Saving Time
C 78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0
e3
C 78 0e 00 08 c0 02 00 14 46 05 05 04 b2 f5 76 REQ Begin std time
C 78 17 08 00 0c 02 00 14 47 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
09
D 78 0e 00 08 c0 02 00 14 66 05 05 00 0b f4 eb REQ date & time
U 78 17 08 00 0c 02 00 14 67 05 05 00 0b 00 74 03 16 02 0d 03 35 00 ec
1e
D 78 0e 00 08 c0 02 00 14 86 05 05 04 b3 f5 b7 REQ Begin
Daylight-Saving Time
D 78 17 08 00 0c 02 00 14 87 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
43
D 78 0e 00 08 c0 02 00 14 a6 05 05 04 b2 f5 d6 REQ Begin std time
D 78 17 08 00 0c 02 00 14 a7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
69
E 78 0e 00 08 c0 02 00 14 c6 05 05 00 0b f5 4b REQ date & time
U 78 17 08 00 0c 02 00 14 c7 05 05 00 0b 00 74 03 16 02 0d 03 36 00 ec
7f
E 78 0e 00 08 c0 02 00 14 e6 05 05 04 b3 f6 17 REQ Begin
Daylight-Saving Time
E 78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
a3
E 78 0e 00 08 c0 02 00 14 06 05 05 04 b2 f5 36 REQ Begin std time
E 78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0
c9
F 78 0e 00 08 c0 02 00 14 26 05 05 00 0b f4 ab REQ date & time
U 78 17 08 00 0c 02 00 14 27 05 05 00 0b 00 74 03 16 02 0d 03 36 00 eb
df
F 78 0e 00 08 c0 02 00 14 46 05 05 04 b3 f5 77 REQ Begin
Daylight-Saving Time
F 78 17 08 00 0c 02 00 14 47 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
03
F 78 0e 00 08 c0 02 00 14 66 05 05 04 b2 f5 96 REQ Begin std time
F 78 17 08 00 0c 02 00 14 67 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
29
G 78 0e 00 08 c0 02 00 14 86 05 05 00 0b f5 0b REQ date & time
U 78 17 08 00 0c 02 00 14 87 05 05 00 0b 00 74 03 16 02 0d 03 37 00 ec
40
G 78 0e 00 08 c0 02 00 14 a6 05 05 04 b3 f5 d7 REQ Begin
Daylight-Saving Time
G 78 17 08 00 0c 02 00 14 a7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
63
G 78 0e 00 08 c0 02 00 14 c6 05 05 04 b2 f5 f6 REQ Begin std time
G 78 17 08 00 0c 02 00 14 c7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
89
H 78 0e 00 08 c0 02 00 14 e6 05 05 00 0b f5 6b REQ date & time
U 78 17 08 00 0c 02 00 14 e7 05 05 00 0b 00 74 03 16 02 0d 03 38 00 ec
a1
H 78 0e 00 08 c0 02 00 14 06 05 05 04 b3 f5 37 REQ Begin
Daylight-Saving Time
H 78 17 08 00 0c 02 00 14 07 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0
c3
H 78 0e 00 08 c0 02 00 14 26 05 05 04 b2 f5 56 REQ Begin std time
H 78 17 08 00 0c 02 00 14 27 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0
e9
A 78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb REQ date & time
U 78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 38 00 ec
01
78 16 01 00 cc 02 00 14 02 15 11 01 fc 00 00 00 00 01 64 00 00 ee 0f
???Bus???
A 78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 REQ Begin
Daylight-Saving Time
A 78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
23
A 78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 REQ Begin std time
A 78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
49
B 78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b REQ date & time
U 78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 39 00 ec
62
B 78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 REQ Begin
Daylight-Saving Time
B 78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1
83
78 13 01 00 cc 02 00 14 02 15 11 01 f5 00 00 00 00 01 f0 9e ???Bus???
B 78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 REQ Begin std time
B 78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1
a9
78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 3a 00 eb
c3 ???Bus???
C 78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 REQ Begin
Daylight-Saving Time
C 78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0
e3
Man kann jetzt noch alle Anfragen für einen Datenpunkt untereinander
schreiben, um den "kleinen Unterschied" besser zu erkennen und dasselbe
auch für die Antworten machen. Programmatisch liefe das auf die
Berechnung der Levenstein-Distanz zweier Zeilen hinaus.
REQ date & time
78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb A
78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b B
78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b C
78 0e 00 08 c0 02 00 14 66 05 05 00 0b f4 eb D
78 0e 00 08 c0 02 00 14 c6 05 05 00 0b f5 4b E
78 0e 00 08 c0 02 00 14 26 05 05 00 0b f4 ab F
78 0e 00 08 c0 02 00 14 86 05 05 00 0b f5 0b G
78 0e 00 08 c0 02 00 14 e6 05 05 00 0b f5 6b H
78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb A
78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b B
78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b C
78 0e 00 08 c0 02 00 14 66 05 05 00 0b f4 eb D
78 0e 00 08 c0 02 00 14 c6 05 05 00 0b f5 4b E
78 0e 00 08 c0 02 00 14 26 05 05 00 0b f4 ab F
78 0e 00 08 c0 02 00 14 86 05 05 00 0b f5 0b G
78 0e 00 08 c0 02 00 14 e6 05 05 00 0b f5 6b H
78 0e 00 08 c0 02 00 14 46 05 05 00 0b f4 cb A
78 0e 00 08 c0 02 00 14 a6 05 05 00 0b f5 2b B
78 0e 00 08 c0 02 00 14 06 05 05 00 0b f4 8b C
REQ Begin Daylight-Saving Time
78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 A
78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 B
78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 C
78 0e 00 08 c0 02 00 14 86 05 05 04 b3 f5 b7 D
78 0e 00 08 c0 02 00 14 e6 05 05 04 b3 f6 17 E
78 0e 00 08 c0 02 00 14 46 05 05 04 b3 f5 77 F
78 0e 00 08 c0 02 00 14 a6 05 05 04 b3 f5 d7 G
78 0e 00 08 c0 02 00 14 06 05 05 04 b3 f5 37 H
78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 A
78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 B
78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 C
78 0e 00 08 c0 02 00 14 86 05 05 04 b3 f5 b7 D
78 0e 00 08 c0 02 00 14 e6 05 05 04 b3 f6 17 E
78 0e 00 08 c0 02 00 14 46 05 05 04 b3 f5 77 F
78 0e 00 08 c0 02 00 14 a6 05 05 04 b3 f5 d7 G
78 0e 00 08 c0 02 00 14 06 05 05 04 b3 f5 37 H
78 0e 00 08 c0 02 00 14 66 05 05 04 b3 f5 97 A
78 0e 00 08 c0 02 00 14 c6 05 05 04 b3 f5 f7 B
78 0e 00 08 c0 02 00 14 26 05 05 04 b3 f5 57 C
REQ Begin std time
78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 A
78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 B
78 0e 00 08 c0 02 00 14 46 05 05 04 b2 f5 76 C
78 0e 00 08 c0 02 00 14 a6 05 05 04 b2 f5 d6 D
78 0e 00 08 c0 02 00 14 06 05 05 04 b2 f5 36 E
78 0e 00 08 c0 02 00 14 66 05 05 04 b2 f5 96 F
78 0e 00 08 c0 02 00 14 c6 05 05 04 b2 f5 f6 G
78 0e 00 08 c0 02 00 14 26 05 05 04 b2 f5 56 H
78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 A
78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 B
78 0e 00 08 c0 02 00 14 46 05 05 04 b2 f5 76 C
78 0e 00 08 c0 02 00 14 a6 05 05 04 b2 f5 d6 D
78 0e 00 08 c0 02 00 14 06 05 05 04 b2 f5 36 E
78 0e 00 08 c0 02 00 14 66 05 05 04 b2 f5 96 F
78 0e 00 08 c0 02 00 14 c6 05 05 04 b2 f5 f6 G
78 0e 00 08 c0 02 00 14 26 05 05 04 b2 f5 56 H
78 0e 00 08 c0 02 00 14 86 05 05 04 b2 f5 b6 A
78 0e 00 08 c0 02 00 14 e6 05 05 04 b2 f6 16 B
Answers "Begin dayligt-saving time"
Requests and associated answers A..H repeat periodically
78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 23
A
78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 83
B
78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 e3
C
78 17 08 00 0c 02 00 14 87 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 43
D
78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 a3
E
78 17 08 00 0c 02 00 14 47 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 03
F
78 17 08 00 0c 02 00 14 a7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 63
G
78 17 08 00 0c 02 00 14 07 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 c3
H
78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 23
A
78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 83
B
78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 e3
C
78 17 08 00 0c 02 00 14 87 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 43
D
78 17 08 00 0c 02 00 14 e7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 a3
E
78 17 08 00 0c 02 00 14 47 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 03
F
78 17 08 00 0c 02 00 14 a7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 63
G
78 17 08 00 0c 02 00 14 07 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 c3
H
78 17 08 00 0c 02 00 14 67 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 23
A
78 17 08 00 0c 02 00 14 c7 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f1 83
B
78 17 08 00 0c 02 00 14 27 05 05 04 b3 00 ff 03 19 ff ff ff ff 16 f0 e3
C
| | |
| | 25
| Mar
Len
Answers "Begin Standard Time"
Requests and associated answers A..H repeat periodically
78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 a9
B
78 17 08 00 0c 02 00 14 47 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 09
C
78 17 08 00 0c 02 00 14 a7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 69
D
78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0 c9
E
78 17 08 00 0c 02 00 14 67 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 29
F
78 17 08 00 0c 02 00 14 c7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 89
G
78 17 08 00 0c 02 00 14 27 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0 e9
H
78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 49
A
78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 a9
B
78 17 08 00 0c 02 00 14 47 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 09
C
78 17 08 00 0c 02 00 14 a7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 69
D
78 17 08 00 0c 02 00 14 07 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0 c9
E
78 17 08 00 0c 02 00 14 67 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 29
F
78 17 08 00 0c 02 00 14 c7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 89
G
78 17 08 00 0c 02 00 14 27 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f0 e9
H
78 17 08 00 0c 02 00 14 87 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 49
A
78 17 08 00 0c 02 00 14 e7 05 05 04 b2 00 ff 0a 19 ff ff ff ff 16 f1 a9
B
| | |
| | 25
| Okt
Len
Answers "Date & Time"
Requests A..H repeat periodically, answers are unique
78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 2d 00 eb f6
unique
78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 2e 00 ec 57
unique
78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 2e 00 eb b7
unique
78 17 08 00 0c 02 00 14 67 05 05 00 0b 00 74 03 16 02 0d 03 2f 00 ec 18
unique
78 17 08 00 0c 02 00 14 c7 05 05 00 0b 00 74 03 16 02 0d 03 30 00 ec 79
unique
78 17 08 00 0c 02 00 14 27 05 05 00 0b 00 74 03 16 02 0d 03 31 00 eb da
unique
78 17 08 00 0c 02 00 14 87 05 05 00 0b 00 74 03 16 02 0d 03 31 00 ec 3a
unique
78 17 08 00 0c 02 00 14 e7 05 05 00 0b 00 74 03 16 02 0d 03 32 00 ec 9b
unique
78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 33 00 eb fc
unique
78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 33 00 ec 5c
unique
78 17 08 00 0c 02 00 14 07 05 05 00 0b 00 74 03 16 02 0d 03 34 00 eb bd
unique
78 17 08 00 0c 02 00 14 67 05 05 00 0b 00 74 03 16 02 0d 03 35 00 ec 1e
unique
78 17 08 00 0c 02 00 14 c7 05 05 00 0b 00 74 03 16 02 0d 03 36 00 ec 7f
unique
78 17 08 00 0c 02 00 14 27 05 05 00 0b 00 74 03 16 02 0d 03 36 00 eb df
unique
78 17 08 00 0c 02 00 14 87 05 05 00 0b 00 74 03 16 02 0d 03 37 00 ec 40
unique
78 17 08 00 0c 02 00 14 e7 05 05 00 0b 00 74 03 16 02 0d 03 38 00 ec a1
unique
78 17 08 00 0c 02 00 14 47 05 05 00 0b 00 74 03 16 02 0d 03 38 00 ec 01
unique
78 17 08 00 0c 02 00 14 a7 05 05 00 0b 00 74 03 16 02 0d 03 39 00 ec 62
unique
| | | | | | | | | | |
Len | | 22 ? | | s ? ? ?
| Mar | 3min
1900+116 13h
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.
Schau mal hier, da gibbet Bilder der Platine usw. https://forum.fhem.de/index.php/topic,29762 Und generell solltet ihr euch mal "treffen" :)
Hallo brha, bezüglich LPB wäre ich auch interessiert, allerdings fehlt mir hierzu ein Interface wie OCI700 um was mitzuschneiden. Mit welchem command kann man z.B. die Anwesenheit an/abschalten... Mein Steuergerät sendet sporadisch die Außentemperatur und die Kesseltemp: Außentemp: 78 11 FF 00 FC 02 00 14 02 05 00 02 1F 00 06 AE F3 85 06AE 1710/64 = 26,72 78 11 FF 00 FC 02 00 14 02 05 00 02 1F 00 06 D8 F3 AF 06D8 1752/64 = 27,xx Kesseltemp: 78 11 F0 00 CC 02 00 14 02 05 00 02 1D 00 05 E4 F3 79 05E4 = 23,xx Grad 78 11 F0 00 CC 02 00 14 02 05 00 02 1D 00 06 24 F2 BA 0624 = 24,xx 78 11 F0 00 CC 02 00 14 02 05 00 02 1D 00 07 2D F2 C4 072D = 28,xx Grüße Gerhard
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.
:
Bearbeitet durch User
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 LPB-BSB, ich hoffe ich habe Deinen Vorschlag vom 11.10.2016 21:53 richtig verstanden Getan habe ich folgendes 120 16 255 0 252 2 0 20 2 5 0 0 105 48 0 244 71 255 in nachfolgende Hexwerte gewandelt 78 10 FF 00 FC 02 00 14 02 05 00 00 69 30 00 F4 47 FF Über CS Rechner https://www.lammertbies.nl/comm/info/crc-calculation.html folgendes zurückbekommen 78 10 FF 00 FC 02 00 14 02 05 00 00 69 30 00 F4 ->0x6BF80 78 10 FF 00 FC 02 00 14 02 05 00 00 69 30 00 F4 47 FF -> 0x336C passt leider nicht. Auf dem A6/MD Pin protokolliere ich nachfolgende Daten 0xC8 12 97 00 00 00 F2 38 4F D5 B1 C7 00 00 00 00 00 00 7F 0xB8 12 97 00 00 00 F2 38 4F D5 A1 C7 00 00 00 00 00 00 8F 0xA8 12 97 00 00 00 F2 38 4F D5 91 C7 00 00 00 00 00 00 9F 0x98 12 97 00 00 00 F2 38 4F D5 81 C7 00 00 00 00 00 00 AF 0x88 12 97 00 00 00 F2 38 4F D5 71 C7 00 00 00 00 00 00 BF 0x78 12 97 00 00 00 F2 38 4F D5 61 C7 00 00 00 00 00 00 CF 0x68 12 97 00 00 00 F2 38 4F D5 51 C7 00 00 00 00 00 00 DF 0x58 12 97 00 00 00 F2 38 4F D5 41 C7 00 00 00 00 00 00 EF 0x48 12 97 00 00 00 F2 38 4F D5 31 C7 00 00 00 00 00 00 FF die CS passt leider auch nicht. Vielleicht nochmal zu meinem Aufbau. Ich habe die Steuerung OHNE ein angeschlossenen Sensor auf meinem Schreibtisch liegen. Hat jemand noch eine Idee?
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 ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
15031112.jpg
3,1 KB
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.
Ich hab nun endlich ein Case gefunden und erhalten, in das ein Arduino Mega zusammen mit BSB-LAN-Platine und POE-fähigem Ethernet-Modul reinpasst. http://www.duinocases.com/store/arduino-enclosures/duinocase-mega-arduino-mega-2560/
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.
:
Bearbeitet durch User
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, ich hätte einen neuen BSB-Adpater von Freetz abzugeben (unbenutzt aus Zeitmangel ;-) Bei Interesse bitte Nachricht an mich. Michael
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#msg682638 https://github.com/fredlcore/bsb_lan Gruß, F.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
toto.jpg
620 KB
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"
Beitrag #6765173 wurde von einem Moderator gelöscht.
Beitrag #6767970 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.