Faktensammlung Buderus EMS

So...
Dann entjungfere ich mal den Thread :p

Anbei das Logfile, ca. 20h lang. Am Bus war nur die Heizung, NetIO mit 
Sniffer und ein RC25. Das Logfile hat vorne ein Timestamp, dann durch 
ein Strich getrennt die Länge, gefolgt von den Daten welche auch mit 
einem Bindestrich abgetrennt wurden.

Mal sehen was man so auswerten kann.

LG

So... Da ich nichtmehr bearbeiten kann wieder einen neuen Beitrag :p

Hier mal meine ersten Statistikversuche in den Datensätzen. Schaut ja 
schonmal gut aus. Ich versuch nun mal die Temperaturreports usw zu 
finden.

Hallo!

Da sind ein paar Nachrichten drin, die in Kombination mit RC35 nicht 
auftreten (0x2a,0xad,0xae). Die bekannten Nachrichten mit 
Temperaturdaten sind aber auch da (0x18/0x19.
Die Busadresse 0x13 ist auch bisher nicht aufgetreten.
Ich sehe mit das Log mal nächste Woche genauer an.

vg

Jürgen

Hallo,
ich Analysiere es gerade ;)
Wenn mich mein Excel bei 40k Zeilen nur nicht laufend verlassen würde. 
(3MB Daten -> 1GB Ram)

Soweit bin ich bis jetzt:

Aus (Mond drücken):
Länge  Sender  Empfänger  Typ  Daten gefolgt von CRC
0x05  0x17  0x00  0xad  0x03  0x00  0xb9

Ein (Sonne drücken):
Länge  Sender  Empfänger  Typ  Daten gefolgt von CRC
0x05  0x17  0x00  0xad  0x03  0x01  0xb8


Raum-Temperatur (0xe3 Byte):
Länge  Sender  Empfänger  Typ  Daten gefolgt von CRC
0x0c  0x17  0x00  0xae  0x00  0x80  0x02  0x2c  0x00  0xe3  0x00  0x00 
0x00  0xf4


Muss ich einfach die Bytefolgen senden um umzuschalden oder kollidieren 
dann die Sender IDs?

Hallo!

Nein, das funktioniert anders. Interpretieren wir mal Deine Bytefolge:

> Aus (Mond drücken):
> Länge  Sender  Empfänger  Typ  Daten gefolgt von CRC
> 0x05  0x17  0x00  0xad  0x03  0x00  0xb9

0x17  Ich bin RC20 ...
0x00  ... und gebe allen bekannt ...
0xad  ... in Telegramm 0xad ...
0x03  ... an Offset 0x03 ...
0x00  ... ist die Einstellung jetzt 0x00 ...

wenn Du senden willst:

0x0b  Ich bin das EMS-GW ...
0x17  ... und sende an RC20 ...
0xad  ... in Telegramm 0xad ...
0x03  ... an Offset 0x03 ...
0x01  ... es werde Tag ;-)   (0 - Nacht, 1 - Tag, 2 - Auto)
CRC

Die RC20 müsste dann mit 0x00 (OK) antworten.

Das EMS-GW darf grundsätzlich nur mit 0x0B als Absender senden !!

Die anderen Einstellungen analog.

PS: Bie der Raumtemperatur musst Du das passende Byte finden. Am besten 
die angezeigte Temperatur mal im Telegramm suchen. z.B. 25,6°C = 0x100 = 
.. 01 00 ..

vg

Jürgen

PS: Denkfehler: Nur Raum- und Waser-Ist-Temperatur hat 10 als 
Multiplikator. Raum-Soll ist x2 und Wasser-Soll x1.

vg

Jürgen

Gut wäre vielleicht, wenn jemand mit WEB KM200 mal die Änderung von 
Betriebsart und Raumsoll mitschneiden könnte. Dann wüssten wir sicher, 
wie so was von "extern" auszusehen hat.

//Niffko

Jürgen Schmied schrieb:
> Die RC20 müsste dann mit 0x00 (OK) antworten.

Ich glaube, das sollte 0x01 heißen, oder? ;)

> Das EMS-GW darf grundsätzlich nur mit 0x0B als Absender senden !!

Da er ein NetIO + Ethersex mit meinem EMS-Code verwendet, ist das schon 
abgesichert: Die Senderadresse und die EMS-CRC wird von Ethersex 
ausgefüllt.

Niffko _ schrieb:
> Gut wäre vielleicht, wenn jemand mit WEB KM200 mal die Änderung von
> Betriebsart und Raumsoll mitschneiden könnte. Dann wüssten wir sicher,
> wie so was von "extern" auszusehen hat.

Betriebsart funktioniert bei mir (RC30) definitiv hiermit:
0x0b 0x10 0x3b 0x07 0x0X <crc>
(für HK1; X = 0 Nacht, 1 Tag, 2 Auto; 0x45 statt 0x3b für HK2).

Die RC30 sendet, wenn ich direkt daran drücke, auch entsprechende 
Meldungen für jeden HK:
0x10 0x00 0x3d 0x07 0x00
0x10 0x00 0x47 0x07 0x00

Wie der Zusammenhang zwischen den Typen (also z.B. 0x3b vs. 0x3d) ist, 
ist mir noch nicht ganz klar. Ich bin mir allerdings ziemlich sicher, 
dass das Kommando stimmt, da ich es aus der Buderus-Doku habe 
(EMS-310809: "Technische Information Logamatic EMS Parameter und 
Monitordaten")

Raumtemperatur geht hiermit:
0x0b 0x10 0x3b 0x0X 0xYZ <crc>

(X = 1 Nacht, 2 Tag, 3 Urlaubsmodus, YZ = Temperatur * 2, also z.B. 
20.5°C -> 41 -> 0x29)

Steht aber alles auch in meinen EMS-Collector-Sourcen ;)

Jürgen Schmied schrieb:
> Die Firmware für das neue Board soll das können, sie besorgt sich per
> NTP die genaue Zeit.
> Ich habs noch nicht probiert, aber ich denke:
>
> 0B 10 06.00 0D 09 14 13 00 00 <CRC>
> ............YY.mm.hh.dd.mi.ss
>
> sollte die Zeit auf den 13.09.2013 20:00 setzen.

Leider funktioniert das nicht :( 0x06 scheint ein Read-Only-Telegramm zu 
sein. Man bekommt zwar ein OK zurück, an der Zeit ändert sich aber nix.

Schade. Versuchs mal Byteweise:

0B 10 06.00 0D
0B 10 06.01 09
0B 10 06.02 14
0B 10 06.03 13
0B 10 06.04 00
0B 10 06.05 00

Vieleicht hat er nur das erste Byte geschrieben !?

Nope :( Ich hab Jahr und Monat (Offset 0 und 1) probiert, selbes 
Ergebnis: OK, aber keine Änderung.

So,
Soll und Ist Temp habe ich schonmal :) Bei dem Tag/Nacht State bin ich 
noch nicht ganz sicher, weis ja aber was beim Umschalten passiert ;)

void
EmsMessage::parseRC20StateMessage()
{
RETURN_ON_SIZE_MISMATCH(9, "RC20 State");      // 9 Nettobytes
printBoolAndAddToDb(1, 7, "Tagbetrieb", Database::SensorWWTagbetrieb);
printNumberAndAddToDb(3, 1, 2, "Soll Raum-Temp.", "°C", 
Database::SensorRaumSollTemp);
printNumberAndAddToDb(4, 2, 10, "Ist Raum-Temp.", "°C", 
Database::SensorRaumIstTemp);
}

und die Switch erweitert mit:

  case addressRC20:
    switch (m_type) {
    case 0xae:
      parseRC20StateMessage();
      handled = true;
      break;
    }
    break;


Das habe ich nun in der EmsMessage.cpp eingefügt ;)

Wie sende ich nun die passende Meldung? Atm. stochere ich noch im 
Blinden rum. Wird das selbst gesendete geloggt? Also die Wiederholung 
der Heizung. Oder wie teste ich sonst was raus geht? :)

LG

So,
habe nun den Logic Analyzer dran hängen (oben TX, unten RX).
Ich habe den Collector umgebaut dass er 0x0B 0x17 0xAD 0x03 0x00 0x88 
sendet. Die Heizung wiederholt Byteweise, danach ist auf dem Bus für 
260ms Ruhe... bis es mit 0x8C weiter geht. Also von einer Antwort des 
RC20 ist da nichts zu sehen. der Collector sagt mir auch Timeout :(

Hoffe Ihr könnt mir nu wieder weiterhelfen :p

Hallo!

Tja, der Empfänger unter 0x17 fühlt sich von einem Schreibbefehl nicht 
angesprochen.

Sende doch mal:
0x0B 0x97 0xAD 0x03 0x01 <CRC>

Dann müsste die BC20 das 4. Byte von Telegramm 0xad zurück senden.

vg

Jürgen

Schaut wieder gleich aus... 260ms keine Antwort :(

Wo ist das Break als Abschluss des Telegramms??? Nach dem CRC muss TX 
für mindestens 10 Bits auf LOW sein.

Okay... dass müsst ich dann in dem NetIO einflicken. Bin grade dabei die 
State Machine darin zu verstehen.

Ra Sp schrieb:
> Okay... dass müsst ich dann in dem NetIO einflicken. Bin grade dabei die
> State Machine darin zu verstehen.

Das ist doch da schon drin?!

Und wieso wirds nicht getan? :)
Hier der Aufruf:

sendCommand(151, type, data, sizeof(data));

151 als Zieladresse? Davon mal abgesehen bin ich mir bei dem 
Ethersex-Code 99.9% sicher, dass der richtig ist, da ich hier ja 
einwandfrei senden kann. Getriggert wird das Break von ems_uart. c:188 
nachdem das letzte TX-Byte raus ist. Du kannst ja spaßeshalber mal 
ethersex aus meinem Fork bei github bauen, einen Unterschied sollte das 
aber nicht machen.

Hmmm vllt. hast du ja auch eine Konstellation wo es passt. Hast du mal 
nachgemessen was effektiv rauskommt?

Ja. So hatte ich auch diesen Bug entdeckt: 
https://github.com/maniac103/ethersex/commit/6a2be5b5a80152da7e14dcee11ad719b9487306a
Der führte dazu, dass das Break verschluckt wurde, wodurch nix ging.
Du kannst den Code gerne nochmal nach Bugs abklappern, grundsätzlich ist 
aber alles da.

So,
hab den Ethersex Code mehrfach durchwühlt. Nun habe ich mir RS232 
Debug-Marken (EMSPROTODEBUG) gesetzt und nun kommen die 11 low-bits... 
Kommentiere ich diese wieder aus, bekomme ich keinen 11-Bit lowpegel. Im 
Moment weis ich grade nicht ob DDRD und PORTD was bringt (habe ich 
eingefügt). Eine Antwort kommt immer noch nicht vom Bus. Mag vllt. am 
Timing liegen dass die 11 Bits zu spät kommen.

static void
start_break(void)
{
  EMSPROTODEBUG("S\n");
  usart(UCSR,B) &= ~(_BV(usart(UDRIE)) |
                     _BV(usart(TXEN))  |
                     _BV(usart(TXCIE)));

  DDRD |= (_BV(PD3));
  PORTD &= ~(_BV(PD3));

  bit_counter = 13; //war 11
  TC2_COUNTER_COMPARE = BIT_TIME;
  TC2_COUNTER_CURRENT = 0;
  TC2_INT_COMPARE_ON;
  state = STATE_TX_BREAK;
}

ISR(TC2_VECTOR_COMPARE)
{
  bit_counter--;
  if (bit_counter == 0) {
    TC2_INT_COMPARE_OFF;
    usart(UCSR,B) |= _BV(usart(TXEN));
    tx_timeout = 0;
  //DDRD &= ~(_BV(PD3));
    go_to_rx();
  EMSPROTODEBUG("E\n");
  }
}


Tante Edit:
So, nun sende ich an 0x17 meine 0xAD Kommandos und es geht :) die 
Heizung schaltet um :) HAPPY

Ra Sp schrieb:
> Im Moment weis ich grade nicht ob DDRD und PORTD was bringt (habe ich
> eingefügt).

Wahrscheinlich nicht, da das Gleiche schon in ems_uart_init() gemacht 
wird und der GPIO danach nicht mehr angefasst wird.

> Tante Edit:
> So, nun sende ich an 0x17 meine 0xAD Kommandos und es geht :) die
> Heizung schaltet um :) *HAPPY*

Und was hast du dafür nun getan?

Tjoa nicht viel auser die 2 Debugmeldungen hinzugefügt. Den rest wie 
oben beschrieben. Ich habe mir nun noch das WebIF erweitert um eine 
Cronfile zu erstellen ;)

Naja erstmal reicht mir das so. Wenn die anderen Projekte fertig sind 
gehts hier weiter ;)

Tante Edit:
Tjoa wie immer... Rechtschreibfehler wurden nach dem posten gesichtet 
und schon korrigiert ;)

Hallo!

Ich habe mal einen kompletten Schreibzyklus incl. Quittierung und 
Busfreigabe aufgezeichnet. So soll es idealerweise aussehen.

vg

Jürgen

... und noch die Anfrage an einen anderen Busteilnehmer.

Hallo zusammen,
könnt Ihr bitte in die Firmware die Initialisierung des LCD Displays mit 
einbauen und einen Begrüsungstext (Versionsnummer der Software) 
ausgeben. Wenn ich demnächst schon mal am Löten der Stiftleisten bin, 
wollte ich gleich mal das Display mit testen.
LG
Stefan

'Die Firmware'? Ich glaube, das wolltest du in den EMS-Gateway-Thread 
posten, oder?

Das hier ist doch der nachfolge Thredd nach Jürgens Wunsch.

lg
Stefan

IMHO nein, siehe meine Antwort im Gateway-Thread. Das hier ist der 
Nachfolgethread für alles, was den EMS selbst betrifft. Wenn wir 
wieder anfangen, alles durcheinanderzumischen, wird der Thread in 
absehbarer Zeit wieder genauso lang...

Hallo!

Die Logamatic 2107M gehört zum 2000er System. Da gibt es kein EMS Bus. 
Auch das Buderus "RS232 Gateway" ist nur für EMS und 4000er.

Ein KM271 würde wohl laufen und bietet eine RS232 Schnittstelle. Da 
brauchst Du aber Logamatic Easycom oder ECO-SOFT (€!).

Das LAN Gateway von Buderus geht auch nur für 4000er.

vg

Jürgen

Hallo zusammen,
Ich verfolge schon seit einigen wochen sämtliche Einträge bezüglich des 
EMS bus von Buderus.
Wollte eigentlich mit einem nand gatter auf die Anlage zugreifen.

Habe da ich meinen Freundlichen Heizungsbauer sehr gut kenne ein 
Web-Gateway KM-200 zum testen bekommen und gleich mal das Ding zerlegt 
da ist ein Bosch Low Ethernet to CAN drin. Habe dann auch gleich mal die 
apk der zugehörigen App zerlegt und jetzt kommt das interesante in der 
App selber sind all Funktionen bereits integriert nur nicht auf aktiv.

Kennt sich denn einer gut mit Java und App Programmierungaus und könnte 
sich den Sorce mal anschauen ob man nicht auf diese Art und weise an 
eine Machtigere Schnittstelle zur Anlage kommt.
Ich wollte eigentlich mit der Platine mit dem Nand gatter und der 
Original Software Eco-Soft die Anlage lesen und Schreiben. Nur über eine 
App wäre das natürlich viel eleganter.

Ich kann auch gerne mal Bilder von dem KM-200 Innenleben machen.
Gruß Alex

Hier nochmal 2 Bilder

Es ist leider nicht viel zu erkennen, außer das dass CAN Interface nicht 
bestückt ist. Kennt jemand einen Mikrocontroller im QFP-128 Gehäuse?

Wenn Du am Laufen hast, kannst du ja mal mit Wireshark testen, wie die 
Kommunikation zwischen KM200 und App läuft.

vg

Jürgen

Hier mal der mitschnitt zwischen der App und dem KM-200

Der KM-200 wird als V850.local angesprochen/aufgelistet mit der IP 
192.168.178.157
nur leider kann ich damit so gut wie nix anfangen alles Spanisch 
Chinesisch oder sonst was für mich.

gruß Alex

Hier noch der sorce der Buderus APK komplett
Orignal APK
Orignal classes.dex
Entpakte APk
Sorce
Umgewandelte classes.dex in classesdex2jar.jar für jd-gui.exe


Anm. Administrator: Anhang entfernt (Urheberrecht beachten!).

Weiß jemand wie ich auf die verschiedene Programme wie Abendprogramm, 
Eigenprogramm usw. umschalte und wo ich genau diese Schaltzeiten finde. 
Kann ich evtl. auch die anderen Schaltzeiten wie beim Eigenprogr. 
verändern? Ich habe die RC30.

Du meinst per RC30 oder per Interface (wie dem EMS-GW) direkt auf dem 
Bus?

Die Telegramme vom Bus findest Du unter 
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme

Dort sind auch die einzelnen Schaltprogramme aufgeführt.

Die Umsschaltung der Betriebsart für Warmwasser bzw. die Heizkreise sind 
dort auch dokumentiert.

vg

Jürgen

Hallo Franz,

also die vorprogrammierten Wochenprogramme sind in der RC30/RC35 fest 
programmiert. Es kann eigentlich nur das "Eigenes Programm" geändert 
werden.

Es gibt aber für jeden Heizkreis ein eigenes Telegramm mit den Zeiten.
Also Urlaubs-/Ferienfunktion und Schaltzeiten

stehen im Wiki bei den Telegrammen...

http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme#hk1schaltzeiten

Der Aufbau der Schaltzeiten ist sind dank Jürgen hier:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme#schaltzeiten_allgemein

Dummerweise habe ich keine Zeiten für die 
Warmwasserbereitung/Zirkulation gefunden. Denke das macht die RC30 
selber und deswegen gibt es wohl keine Telegramme dafür ?!?

Gruß
Ingo

Da war Jürgen wohl schneller...

Jürgen Schmied schrieb:
> Warmwasser

Das ist ja interessant... Scheint das Telegramm 0x38 zu sein.

Zumindest bei der RC35 ist Telegram 0x39 das Schaltprogramm für die 
Zirkulation. Was die RC30 alles steuert, weiß ich leider nicht. Dazu 
müsste man mal einen längeren Busmitschnitt so einer Anlage haben ...

Hat jemand die Möglichkeit?

vg

Jürgen

Hallo Ingo,
hallo Jürgen,

Ingo F. schrieb:
> stehen im Wiki bei den Telegrammen...
> 
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:telegramme#hk1schaltzeiten

die Wiki habe ich gelesen, hier geht aber nicht hervor wie ich auf die 
verschiedene Programme wie Abendprogramm, Singleprogramm, Eigenprogr. 
umschalte.

Ingo F. schrieb:
> also die vorprogrammierten Wochenprogramme sind in der RC30/RC35 fest
> programmiert. Es kann eigentlich nur das "Eigenes Programm" geändert
> werden.

das habe ich mir gedacht, ich müßte aber die Zeiten trotzdem auslesen 
können, bzw die Zeiten vom Eigenprogr. ändern können.
Im Wiki habe ich nur die Urlaubszeiten (Typ 0x3f) gefunden. Gibt es eine 
Aufschlüsselung der Schaltzeiten der RC35 Typ 0x49 und Typ 0x4c

Ingo F. schrieb:
> Dummerweise habe ich keine Zeiten für die
> Warmwasserbereitung/Zirkulation gefunden. Denke das macht die RC30
Im Wiki steht 0x38 und 0x39 aber ich weiß nicht, ob es die 
Urlaubsfunktion ist.

Jürgen Schmied schrieb:
> Zumindest bei der RC35 ist Telegram 0x39 das Schaltprogramm für die
> Zirkulation. Was die RC30 alles steuert, weiß ich leider nicht. Dazu
> müsste man mal einen längeren Busmitschnitt so einer Anlage haben ...
>
> Hat jemand die Möglichkeit?

Ich lass meinen Daemon mal einen Tag mitloggen. Ich glaube allerdings, 
dass das Durchsehen mühselig wird, oder hast du Skripte, um das zu 
analysieren?

Hallo Danny,
leider habe ich keine Skripte, mal eine Frage: Wenn ich das 
Schaltprogramm an der RC30 ändere, werden diese Daten dann auf den 
EMS-Bus sofort gesendet?

Viele Grüße
Franz

Das Schaltprogramm ist im Speicher der RC30. Diese sendet auch die
Steuerbefehle zu den programmierten Zeitpunkten zu dem Brenner, Pumpe 
usw.

Zusätzlich wird das Schaltprogramm als Kopie auf den Bus gesendet - aber 
anscheinend nur zur Information für andere Teilnehmer. Ohne die RC30/35 
passiert nichts.

vg

Jürgen

PS: Umschaltung in den Urlaubsmodus:
Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung"

PSS: Ja, ich habe ein Java-Programm, um den binären Byte-Stream vom 
EMS-GW auszuwerten. Es übersetzt ihn in in Text und den kann normal 
durchsuchen.

vg

Jürgen

Auch nach einem base64 Decoder ist es immer noch kein JSON oder 
Binary-JSON. Also komplett unlesbar.

js

Jürgen Schmied schrieb:
> Zumindest bei der RC35 ist Telegram 0x39 das Schaltprogramm für die
> Zirkulation. Was die RC30 alles steuert, weiß ich leider nicht. Dazu
> müsste man mal einen längeren Busmitschnitt so einer Anlage haben ...

So in etwa? ;) Sind die Nachrichten von ~16h Laufzeit meiner Anlage - 
von gestern abend bis gerade eben.

Ja, so in etwa. Stimmt es, dass Du ein MM10 und WM10 Modul sowie 2 
Heizkreise in der Anlage hast? Der Kessel ist auf 58% max Leistung 
gedrosselt? Die Anlage ist 7326h in Betrieb?

Komisch ist:
HK2 Raum-Solltemperatur             0.0 °C
Warmwasser-Soll-Temperatur          10.0 °C
Brennerstarts                       100149

Es gibt wieder neue Telegramme zum entschlüsseln ;)

vg

Jürgen

Jürgen Schmied schrieb:
> Ja, so in etwa. Stimmt es, dass Du ein MM10 und WM10 Modul sowie 2
> Heizkreise in der Anlage hast? Der Kessel ist auf 58% max Leistung
> gedrosselt?

Ja. Die Drosselung hast du gesehen, weil bei Warmwasserbereitung auch 
nur 58% anliegen, oder?
Edit: Ach nee, max. Leistung ist ja Teil der MonitorFast-Message.

> Die Anlage ist 7326h in Betrieb?

Das ist doch Brennerlaufzeit, nicht Anlagenbetriebsdauer, oder? Dürfte 
dann hinkommen; die Anlage ist seit 2004 in Betrieb.

> Komisch ist:
> HK2 Raum-Solltemperatur             0.0 °C
> Warmwasser-Soll-Temperatur          10.0 °C

Wann war das, evtl. nachts?

> Brennerstarts                       100149

Hmm, das wären etwas mehr als 10000 im Jahr oder 30 am Tag ... erscheint 
mir in Anbetracht der Tatsache, dass es heute bislang 15 waren, nicht 
komplett unmöglich, wenngleich etwas hoch. Wir sind allerdings erst 2009 
eingezogen; ich habe keine Ahnung, mit welchen Parametern die Anlage 
vorher betrieben wurde.

Hallo!

So, hier das Log in lesbarer Form. Habe die neuen Telegramme im Wiki 
eingefügt.

vg

Jürgen

Hallo Jürgen,
gute Arbeit, mit was für einem Programm schreibt Ihr die Protokolle mit? 
Ist es möglich die Daten auf SD-Karte zu sichern um sie dann mit einem 
Hex-Editor auszulesen?

viele Grüße
Franz

Hallo,

Danny Baumann schrieb:
>> Brennerstarts                       100149

Habe hier seit 06.2010 ca. 38.600 Brennerstarts. Das sind rund 30 pro 
Tag. Deckt sich mit Deinen Angaben.

Gruß aus der derzeit kalten Wetterau
Karl M.

ps. Habe mich jetzt auch mal registriert. Charlies gibt's ja wie Sand am 
Meer. :-o

Hi,

also ich liege mit einer GB172-24 bei 5-6 Starts pro Stunde im SCHNITT, 
da kommst du ja noch gut weg.

Gruss
Norbert

> die andauernden Brennerstarts gingen mir damals 2006/2007 als unsere
> GB-132 16 neu war, gerade in der Übergangszeit auch auf den Nerv, da
> halt nicht wirklich Bedarf da ist und so hatte die ohne Ende getaktet.
> Ich habe damals (zusätzlich zu weiteren Optimierungen, Heizkurve, ...)
> eine Sperrzeit eingestellt, sodass der Brenner erst nach frühestens
> 45min erneut starten darf.

Das ist interessant. Wie hast du das gemacht?

giovanne schrieb:
> eine Sperrzeit eingestellt, sodass der Brenner erst nach frühestens
> 45min erneut starten darf.

Ja, würde mich auch interessieren.
Hab hier 'ne Buderus GB162-25 T40S.

Hi,

auf dem RC35 die beiden rechten und den linken Knopf gleichzeitig 
drücken, dann ist man im 'richtigen' Menü, dann müsste das bei den 
Heizkreiseinstellungen sein.

Gruss
Norbert

Machts doch nicht spannend. Na, wer kennt es? ;)

Wie vermutet, in den Sonderparametern -> Antipendelzeit

Giovanne Giovanne schrieb:
> Wie vermutet, in den Sonderparametern -> Antipendelzeit

Hi,

danke für's rauskramen! Leider komme ich da nicht ran, habe keine 
Ecosoft.
Kennt jemand die Telegrammparameter?

Gruß aus der Wetterau
Karl M.

Hallo!

Ich rate mal:

08 00 16|00 FF 5A 64 00 06 FA>0A<01 0B 64 37 02|2E

Die 0x0a könnte der gesuchte Wert sein.
Die 0x0b ist der Kesselpumpennachlauf (hier 11 Min).

vg

Jürgen

Sollte passen, ein Mitschnitt per 3964R Terminal während des Ecosoft 
Betriebes zeigt die Werte zum Zeitpunkt wenn für das Online Monitoring 
neu eingelesen/initialisiert wird:

Folgende Werte sollten zu meinen Einstellungen passen:
(Mitschnit sieht so aus, da ich derzeit nur lese per 3964R Terminal, da 
ja Ecosoft die sende-Befehle Hoheit hat ;-)
1384909781306 - COM12 - (z00) receive: <<04>>. Rejecting.
1384909781306 - COM12 - (z00) receive: <<08>>. Rejecting.
1384909781306 - COM12 - (z00) receive: <<16>>. Rejecting. => Telegramm
1384909781306 - COM12 - (z00) receive: <<00>>. Rejecting.
1384909781322 - COM12 - (z00) receive: <<FF>>. Rejecting. => 255 ?
1384909781322 - COM12 - (z00) receive: <<5A>>. Rejecting. => 
Kesseltemp.: 90°
1384909781322 - COM12 - (z00) receive: <<32>>. Rejecting. => 50 ?
1384909781322 - COM12 - (z00) receive: <<00>>. Rejecting.
1384909781322 - COM12 - (z00) receive: <<06>>. Rejecting. => 6 ?
1384909781338 - COM12 - (z00) receive: <<FA>>. Rejecting. => 250 ?
1384909781338 - COM12 - (z00) receive: <<2D>>. Rejecting. => 
Antipendelzeit: 45min
1384909781338 - COM12 - (z00) receive: <<01>>. Rejecting. => 1 ?
1384909781338 - COM12 - (z00) receive: <<1E>>. Rejecting. => 
Kesselpumpennachlauf: 30min
1384909781338 - COM12 - (z00) receive: <<50>>. Rejecting. => 
Kesselkreispumpenmodulation max. Leistung: 80
1384909781338 - COM12 - (z00) receive: <<37>>. Rejecting. => 
Kesselkreispumpenmodulation min. Leistung: 55


Ach ja, schön wäre wenn man das 3964R Terminal nur zum Lauschen nutzen 
könnte und die Daten bereits korrekt aufbereitet würden (inkl. 
Erkenntnisse aus 
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:sk_schnittstelle 
bzgl. Änderungen) und von dort in eine DB geschrieben werden könnten.
Tue mich da derzeit noch ein wenig schwer :-(

Ok, ist im Wiki eingepflegt.

Verdächtig ist noch Byte 7: bei mir 0x64 (warscheinlich 100%) bei Dir 
0x32 (warscheinlich 50%). Ideen?

Zum Rest fällt mir erstmal nichts ein.

vg

Jürgen

bzgl. 0x32 (warscheinlich 50%) sehe ich noch keine direkt Zuordnung in 
den Parametern.
Wenn eine 1 davor wäre, hätte es theoretisch Mischerlaufzeit = 150sek. 
bei mir sein können.

Bei den Sonderparameter (s. Screengrab oben), wären noch 
Temperaturanhebungen für HK1 (bei mir 5), HK2 (bei mir 5) und WW (bei 
mir 15) in Kelvin, welche ich aber auch noch nicht im Protokoll 
wiedergefunden habe.



Ich könnte es alles einfacher lesen, wenn das 3964R Terminal im rein 
lesenden Betrieb die Daten/Protokolle sauber rausfischen könnte ;-)

IngoF schrieb:

alles schon klar, deshalb ja auch provokant geschrieben. Evtl. hätte 
sich ja jemand gefunden der auch die Originalsoftware nutzt und dann 
einfach die Daten hithorchen möchte und diese in eine DB schreiben will 
und beim Programmieren/Herausfischen der Daten schneller ist ;-), da 
dies bei der Original Ecosoft nur über riesige Umwege / bis garnicht 
möglich ist.
Ich habe bestimmt eher ne neue Heizung als das ich fertig bin ... ;-)

> ist halt nicht einfach dem 3964R-Terminal das Handshake abzugewöhnen.
> Ist halt nicht dafür gedacht das Drei Busteilnehmer an einem Serial-Port
> hängen.

ist schon klar, deshalb verwende ich ja auch com0com um zumindest aus 
einem zwei separate virtuelle COMs zu machen. Funktioniert auch soweit. 
In com0com bzw. hub4com kann sogar direkt die 
Datenweiterleitung/Flusssteuerung bestimmt werden.

>
> Da das 3964R-Terminal eine fertige Bibliothek verwendet müsste man die
> Bibliothek entsprechen umbauen oder selber schreiben.
>
> Also am besten Service-Key oder eine andere Software.
>
> Vermutlich wäre für so kurze Mitschnitte "hTerm" besser geeignet. Am
> besten das Handshake vom 3964R-Protokoll für einen Zeilenwechsel beim
> hTerm einstellen. Wird dann vermutlich viel übersichtlicher.
> Dann muss man aber noch die doppelten 0x10 herausfiltern.

kann ich für kurze Mitschnitte / Protokollanalysen ja mal probieren, 
mein End-Ziel sind aber ja keine kurzen Mitschnitte ;-)

>
> Wenn man dem 3964R-Terminal das schreiben in die Datenbank "beibringt"
> müsste man also auf den Service-Key verzichten.
>
> ...Oder ein komplett neues Programm schreiben dass das Handshake
> ignoriert und nur die Daten herausfischt...

genau, vom 3964R Terminal spreche ich ja nur weil da als Grundlage schon 
etwas da ist und die benötigten Daten im Trace bereits auftauchen, aber 
halt nicht als solche zusammenhängend erkannt werden.
Ich könnte nun etwas nachschalten, was aus den erzeugten Logfiles die 
Daten/Protokolle heraussucht und in die DB schreibt, oder aber wie Du 
schon schreibst von Null anfangen...

Mal schauen, zumindest scheint es nicht viele zu geben die die Original 
HW/SW haben und dort mithorchen wollen. Ihr habt ja alle Eure eigene HW.

Thema braucht Ihr aber in dem Thread nicht weiter fortführen... wenn 
jemand gleiche Interessen hat kann man sich ja ggf. erstmal per PN 
austauschen.

IngoF schrieb:
> Ich glaub wir reden aneinander vorbei...
>
> Es macht ja in meinen Augen kein Sinn zwei Programme mitloggen zu
> lassen.
> Also entweder Original-Software ODER Eigene Software.
klar, wenn die Eigenentwicklung irgendwann ALLES kann was die Original 
Soft kann. Da werde ich aber nie hinkommen (wollen).
Somit möchte ich nur mithorchen und "täglich" wichtige Daten in die DB 
für schnelles nachschauen schreiben.
Für detaillierte Informationen ist sicherlich die Originalsoft besser, 
nur leider läßt sich in den Aufzeichnungen dort nicht einfach suchen 
geschweige denn einfach in eine DB zu schreiben. Zudem ist die Soft 
blockiert wenn sie 24/7 loggt/aufzeichnet.

>
> Sicher für eine Übergangslösung bis die eigene Software läuft ist das
> OK.
>
> Sobald auch nur noch eine Software am Service-Key hängt haben sich die
> Handshake-Probleme gelöst.
>
> Deswegen macht es wenig Sinn eine Spezielle Software zu schreiben die
> ohne einen Dritten neben dem Service-Key funktioniert .
wie oben geschrieben schon, da die Eigenentwicklung ja bzgl. Handshake 
garnichts machen soll. Macht ja die Originalsoft.
Eigenentwicklung: Horchen, Erkennen, Wegschreiben.

>
> Also zum Mittloggen um die Funktion zu erkennen ist bestimmt H-Term
> besser...
schau ich mir an...

>
> Da ich ja keinen Service-key habe kann ich schlecht die Software dafür
> schreiben.
>
> Habe Dir ja meinen Quelltext im SVN zur Verfügung gestellt. Aber kann
> nicht beim Programmieren helfen wenn die Weiterentwicklung nicht im SVN
> stattfindet.
Ist ja noch keine Weiterentwicklung. Eher Quick & Dirty um Erfahrungen 
zu sammeln. Als Weiterentwicklung ist es ja nicht geeignet, da ja z.B. 
kein Handshake behandelt würde und somit "3964R" nicht mehr passt.
Wenn ich was hätte würde ich es sofort hochladen, derzeit würde aber 
jeder über das Quick&Dirty lachen ;-)

>
> Aber ich habe ja sowieso keine Langeweile, eher im Gegenteil...
>
hab ich auch nicht, deshlab geht es ja nicht so schnell. Und kann nur 
abends/nachts weiter gehen.

Zudem werde ich dann sicherlich eher eine neue Heizung haben ehe die 
Soft alles kann was die Originale kann.

Aber Thema braucht hier nicht weiter diskutiert werden. Also Schluß 
damit ;-)


Also kommt zurück zum Thema, würde Euch bei weiteren Bestandteilen der 
fehlenden Protokolle helfen. Vieles ist wohl in der 
Initialisierungsphase des Online-Monitoring der Eco-Soft mit ganzen 
Telegrammen enthalten...kann es derzeit halt nur nicht "komfortabel" 
lesen... ;-)

Hi all!

@Giovanne und Jürgen
Herzlichen Dank für Euer Bemühen und Eure Arbeit.

@Danny
Hast Du vor, die MC10 Parameter (0x16) in Deine Software einzupflegen?

Für meine RC35 habe ich in der EMSMessage.cpp folgendes geändert:
* RETURN_ON_SIZE_MISMATCH (28, "MonitorSlow");
* RETURN_ON_SIZE_MISMATCH (18, "MonitorWW");
* RETURN_ON_SIZE_MISMATCH (17, text);
Würde es Deiner Meinung nach Sinn machen, die RC20 / RC35 über eine 
Abfrage automatisch vorzubelegen?

Falls es jemanden interessieren sollte:
Meine Buderus GB162-25 T40S spuckt auch den aktuellen 
Warmwasserdurchfluss aus. Folgendes habe ich dazu in den folgenden Files 
(von Danny) ergänzt:
---
Database.cpp
   query.execute(SensorWarmwasserDurchfluss, sensorTypeNumeric,
      "Warmwasserdurchfluss", readingTypeVolume, "l/min", 1);
Database.h
   SensorWarmwasserDurchfluss = 26,
   static const unsigned int readingTypeVolume = 7;
EMSMessage.cpp
   printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min",
      Database::SensorWarmwasserDurchfluss);
www/ems/constants.php.inc
   define('SensorWarmwasserDurchfluss', 26);
   define('ReadingTypeVolume', 7);
www/ems.php
   print_cell("WW-Durchfluß", $sensors[SensorWarmwasserDurchfluss]);
---

Danke noch mal an Alle, die hier eine hervorragende Arbeit geleistet 
haben.

Gruß aus der Wetterau
Karl M.

Hallo,
ich habe mir mal die Wiki Telegramme genauer angeschaut, dabei sind mir 
einige Fehler oder Unregelmäßigkeiten aufgefallen. Könnt Ihr den Anhang 
mal nachschauen?
Ich frage mich, wie bei den Bits die Zählweise hier ist. Bit 1..8 gleich 
von links nach rechts? Ich zähle immer Bit 7..0 also Bit 0 ist bei mir 
rechts.

Viele Grüße
Franz

Danke Ingo,
sollte man evtl. noch ändern. Bei der Byteanzahl komme ich auch nicht 
weiter. Hier könnte man auch Hi und Lo dazu schreiben.

Viele Grüße
Franz

Hallo,
IngoF schrieb:
> Die Bitzählweise auf 0-basiert umgestellt

Danke, das ist für mich jetzt übersichtlicher zu lesen. Macht es einen 
Sinn, anstatt des Startwertes den Offset (=Startw.-5) zu nehmen?

Jetzt habe ich nur noch einen Fehler bei den Bits gefunden:
08 00 34 Startw. 10

Ich habe mal einen Frage zur Antipentelzeit:
08 00 16 Startwert 11
was bedeutet der Wert in Minuten genau? Ist es die Mindeststandzeit?

Da mein Brennwertgerät bei kleiner Last ständig ein- und ausschaltet 
habe ich mal etwas getestet. Dabei habe ich zwei Werte herausgefunden:
08 00 16
Startwert 9: Abschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist
Startwert 10: Einschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist 
(Wert ist hier negativ).
Was mir noch nicht ganz klar ist, ob der Frostschutz hier noch 
garantiert ist, wenn ich den Wert vom Einschaltpunkt zu tief setze.
Viele Grüße
Franz

> Ich habe mal einen Frage zur Antipentelzeit:
> was bedeutet der Wert in Minuten genau? Ist es die Mindeststandzeit?
Das ist die Zeit nach Stopp des Brenners, welche mindestens vergehen 
muss, bevor der Brenner wieder gestartet werden kann.

Die anderen Änderungen sind im Wiki.

vg

Jürgen

Hallo Jürgen,

Jürgen Schmied schrieb:
> Das ist die Zeit nach Stopp des Brenners
das muß ich nochmal überprüfen, mir ist die Zeit kürzer vorgekommen.

Jürgen Schmied schrieb:
> Die anderen Änderungen sind im Wiki
danke, die Einheit müßte aber °C bzw. Kelvin sein.

Ich habe noch etwas herausgefunden,
08 00 16 Startw. 7 Kesselleistung_max
08 00 16 Startw. 8 Kesselleistung_min? Dieser Wert geht aber immer 
wieder auf Null

was mich interessiert, mein Kessel fährt mit einer Mindestleistung von 
20%, obwohl ich weniger Leistung benötige. Kann ich diese Leistung 
irgendwo einstellen? Oder ist diese fest?

Viele Grüße
Franz

> was mich interessiert, mein Kessel fährt mit einer Mindestleistung von
> 20%, obwohl ich weniger Leistung benötige. Kann ich diese Leistung
> irgendwo einstellen?
Der Brenner hat eine Minimalleistung, mit der er moduliert werden kann. 
Die kannst Du nicht unterschreiten.

vg

Jürgen

Hallo,
danke für die Antwort.
Jürgen Schmied schrieb:
> Der Brenner hat eine Minimalleistung, mit der er moduliert werden kann.
> Die kannst Du nicht unterschreiten.

dann muß ich die Leistung bei 20% lassen.

F. F. schrieb:
> Startwert 9: Abschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist
> Startwert 10: Einschaltung wenn Vorlauf_Soll + Wert(Kelvin)= Vorlauf_Ist
damit habe ich das ständige Ein- und Ausschalten stark reduziert.

Jürgen Schmied schrieb:
> Das ist die Zeit nach Stopp des Brenners
Das trifft bei mir nicht ganz zu (RC30). Als Antipentelzeit habe ich 20 
Minuten (0x14), den Ein- und Ausschaltpunkt um jeweils 10°C Differenz 
eingestellt. Nach einer Brennerlaufzeit von über einer Stunde hatte ich 
+10°C erreicht. Der Brenner ging aus, als Service-Code kam 0Y. Nach 6 
Minuten Standzeit hatte ich eine Differenz von -10°C vom Sollwert und 
der Brenner sprang sofort an. Kann es sein, daß die 20 Minuten die 
gesamte Periode aus Brennerlaufzeit und -standzeit ist? Bei kürzere 
Laufzeiten hatte ich nach dem Einschaltdelta den Code 0A und der Brenner 
stand noch eine Weile, aber weniger als 20 Minuten.

Ich habe noch eine Frage zum "Optimierung Schaltprogramm" (10 3d Startw 
24) Was macht das genau? Bedeutet das bei Raumtemperaturgeführt, das die 
Heizung rechtzeitig einschaltet? Ich habe diesen Punkt für HK2 testweise 
gesetzt.

Viele Grüße
Franz

ich habe noch eine Unklarheit:
bei UBAMonitorFast 08 00 18 Startw. 12 (Offset 07) habe ich wenn der 
Brenner läuft 0x25 (0010 0101) danach müßte die Gasarmatur (Bit 0) ein 
sein. Kesselkreispumpe (Bit 5) ist ein.
Auf der Web-Seite bekomme ich hier aber Gasventil ein, Zündung ein, 
Kesselpumpe und Zirkulationspumpe aus. Ist Kesselpumpe und 
Kesselkreispumpe das gleiche? Dann stimmt etwas mit der Seite nicht.

in Ecosofts graf. Darstellung wird Bit 5 als "Kessel 
1:Heizkreis-/Zubringer Pumpe" bezeichnet und Bit 0 (Gasarmatur) als 
"Flammensignal".


08   00   18   12   Bit0   1     digital     Gasarmatur EIN  => Kessel 
1:Flammensignal
08   00   18   12   Bit2   1     digital     Gebläse EIN     => Kessel 
1:Gebläsemodulation
08   00   18   12   Bit3   1     digital     Zündung EIN     => Kessel 
1:Zündung
08   00   18   12   Bit5   1     digital     Kesselkreispumpe EIN  => 
Kessel 1:Heizkreis-/Zubringer Pumpe
08   00   18   12   Bit6   1     digital     3-Wege-Ventil auf WW => 
Warmwasser:WW-Laden
08   00   18   12   Bit7   1     digital     Zirkulation EIN  => 
Warmwasser: Zirkulationspumpe

in Anhang Beispiel 0x25 mit bisherigen Bezeichnungen.

so steht es im Wiki auch, auf der Web-Seite bekomme ich aber immer 
"Kesselpumpe aus" obwohl das Bit 5 gesetzt ist. (0x25)

ok sorry, da kann ich nicht mitreden. Ich kenne die Webseite nicht :-(

auf Deinem Bild oben ist auch Zündung weiß und Zubr. Pumpe grün? 0x25?

ja
Zündung Bit3 = 0
Zubringer Bit5 = 1

0x25 => 00100101

auf der Web-Seite habe ich für 0x25:

Gasventil  ON
Gebläse  OFF
Zündung  ON
Kesselpumpe  OFF
Zirkulationspumpe  OFF
3-Wege-Ventil-WW  OFF

Ich habe mal den Ablauf beim Starten und Stoppen des Brenners 
zusammengestellt. Da ist der Ablauf gut zu sehen.
Ecosoft wird schon Recht haben ;)

vg

Jürgen

die rechte Ziffer ist das der Fehlercode? Hier bekomme ich immer 0 
angezeigt. Kann aber sein, weil ich kein Fehler habe und die RC30 
besitze. (Evtl. wird es auch durch die Endemarkierung vom Servicecode 
auf Null gesetzt?).

Zur Info, bei mir ist es auch RC30.

ok, ich glaube da ist ein Fehler in emsProtokoll.h. Habe mal meine 
Version unter emsProtokoll_geaendert.h hochgeladen.

> die rechte Ziffer ist das der Fehlercode? Hier bekomme ich immer 0
> angezeigt.
Hallo der Fehlercode ist in der FW 8bit statt 16bit. Daher meistens 0. 
Ich ändere das. Den Rest muss ich mir in Ruhe ansehen.

vg

Jürgen

A propos Dokumentationsprobleme: Kann jemand mit Durchlauferhitzer 
(GB152, richtig?) mal bitte posten, wie die 'Monitor WW'-Nachricht 
(0x34) bei ihm aussieht? Ich habe den Verdacht, dass die Doku für den 
Typ des WW-Systems (Byte 13) falsch ist. Ich bekomme bei mir 0x3, was 
laut Doku 'keins + Durchlauferhitzer' heißt - das ergibt einfach keinen 
Sinn. Ich denke, dass man das Ganze als Werte (d.h. 0, 1, 2, 3, 4 
anstatt 1 << 0, 1 << 1, 1 << 2, 1 << 3, 1 << 4) interpretieren muss 
(dann käme bei mir korrekterweise 'großer Speicher' raus), ich würde das 
aber mal gerne noch verifizieren ;)

Hallo!

Diese Bits sollten so stimmen. Die waren mal in einem Dokument 
(8718575620 – 09/2009 DE) drin, welches aber inzwischen nicht mehr in 
den Downloads zu finden ist.
Das Logamatic EMS RS232 Gateway hatte anfangs mal den EMS Bus direkt 
unterstützt, da sind einige der Felder offiziell dokumentiert gewesen.

vg

Jürgen

Hallo!

Ok, so wie sie dokumentiert sind, gibt es keinen Sinn. Bei mir wäre das
{UBAMonitorWWMessage:WW-System: kein}                     AN
{UBAMonitorWWMessage:WW-System: Durchlauferhitzer}        AN
{UBAMonitorWWMessage:WW-System: kleiner Speicher}         AUS
{UBAMonitorWWMessage:WW-System: großer Speicher}          AUS
{UBAMonitorWWMessage:WW-System: Speicherladesystem}       AUS

wenn man das als 0x03 "kleiner Speicher" deutet, wäre es Ok. (Sind 240L 
klein?).
Hat jemand etwas anderes als 3 drin?

vg

Jürgen

Auf der Web-Seite steht beim RS232 Gateway: "Offenlegung 
Kommunikationsprotokoll zu Logamatic auf Anfrage" von EMS ist nur im 
Zusammenhang mit ECO-SOFT die Rede. Das Dokument, welches das EMS 
Protokoll dokumentiert ist nirgends mehr auf der offiziellen Seite zu 
finden.

Ich denke auch, das "Logamatic web KM200" ist inzwischen der Nachfolger 
von RS232 Gateway.

vg

Jürgen

müßte wie im der doku/wiki passen:
Monitor WW - Typ 52
Offset 8
Art des Warmwassersystems
1. Bit = kein Warmwassersystem vorhanden
2. Bit = Durchlauferhitzer
3. Bit = kleiner Speicher
4. Bit = großer Speicher
5. Bit = Speicherladesystem -> ab Ver: 3.0
6. Bit bis Bit 8 = frei

Passt ja eben nicht: bei mir steht hier 0x03 drin. Ich habe aber ein 
GB152 mit Speicher und nicht gleichzeitig "kein Warmwassersystem 
vorhanden" und "Durchlauferhitzer" ...

ok bei GB152 kann ich auch nicht helfen.

...werde mal sehen ob ich den Datentyp 52 beim Ecosoft mal mitlauschen 
kann, dann kann ich zumindest sehen wie es zum GB132/EMS/160 l-Speicher 
passt...

Edit: ist bei mir auch derzeit mit 0x03 belegt, kann ich also 
bestätigen, passt irgendwie nicht zur Doku.

Edit2: Ecosoft weiss jedoch das ein Speicher vorhande ist ;-) Mal sehen 
woher ...

ich habe eine GB142, einen Boiler 240l? Beim mir steht auch 0x03.

Hallo,
kennt ihr "Technische Information Monitordaten System 4000"?
Da habe ich auf Seite 34 die Monitorwerte für Störmeldemodul Typ 0x9c 
gefunden. Ich denke, daß dies die Werte vom Wiki WMStatus2 bzw 
WMParameter sind.
https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CD0QFjAB&url=http%3A%2F%2Fwww.ip-symcon.de%2Fforum%2Fattachment.php%3Fattachmentid%3D13808%26d%3D1320956568&ei=AqGsUrmrHoiAtAbP0ICQCg&usg=AFQjCNGM-sq-a6zyIivMQwbdxqWX-GnXhQ&sig2=XhjWX0LTiHP7nwxO-w5LrQ
Viele Grüße
Franz

Hallo!

Ja, das würde sehr gut passen. Möglicherweise sind auch noch andere 
Bytes damit erklärbar. Muss ich mal testen, wenn ich Zeit finde ...

vg

Jürgen

ich habe in Wiki dieses Bit geändert:
10  00  3E  6  7  1    digital    Party- Pausebetrieb
es steht für Party oder Pause-Betrieb

Hallo,

ich baue gerade ein kleines Interface für einen RPi und beschäftige mich 
erstmalig mit der gezielten Abfrage von EMS-Daten. Bis jetzt hatte ich 
mir immer nur die benötigten Daten vom Bus gepickt.

Was ich festgestellt habe ist, dass Anfragen an den Master(0x08) sehr 
oft beim ersten mal nicht beantwortet werden. Das nächste mal, beim 
darauf folgenden Polling, klappts dann aber immer.

Kennt dieses Verhalten jemand, oder habe ich noch irgendeinen Knoten in 
der Software?


//Niffko

Hallo Jürgen,
mir ist mit Telnet aufgefallen, das das Brennwertgerät die gesendeten 
Daten annimmt ich aber nicht immer auf eine Anfrage eine Antwort 
bekomme, manchmal fehlen auch ein paar Bytes. Auch bei der JSON-Abfrage 
bekomme ich nicht immer eine Antwort. Vielleicht hilft das weiter.

IngoF schrieb:
> Bei mir ist es schon länger her dass ich testweise mal ein paar Werte
> abgefragt habe. Die Antwort kam immer nach der ersten Abfrage. (Datum/
> Uhrzeit und Partymodus/Urlaub.

Diese beiden Dinge kommen ja auch von der RC ;)

Mir ist beim Abfragen der Fehlercodes auch schon aufgefallen, dass 
meistens keine Antworten vom UBA kommen. Ich habe dann einen 
Retry-Mechanismus eingebaut: 
https://github.com/maniac103/ems-collector/commit/649eab5cf6726b76e9270baf39f71399ec99dd5c 
Nach meiner Beobachtung macht die RC30 genau das gleiche, scheint also 
normal zu sein.

>[...unbeantwortete Abfragen...]
ok, dann scheint das offensichtlich normal zu sein.

Danny Baumann schrieb:
> Ich habe dann einen Retry-Mechanismus eingebaut ...
joa, habe ich auch getan.

@Danny
Mal interessenhalber: Sendest Du bei nicht erfolgter Antwort noch eine 
Busfreigabe(0x0B) oder lässt Du einfach "weiterlaufen"?


//Niffko

Niffko _ schrieb:
> @Danny
> Mal interessenhalber: Sendest Du bei nicht erfolgter Antwort noch eine
> Busfreigabe(0x0B) oder lässt Du einfach "weiterlaufen"?

Wenn ich mich recht entsinne (der Lowlevel-Kram ist schon so lange her 
;) ), lässt mein Ethersex-Code an der Stelle einfach weiterlaufen. Das 
0xb wird nur gesendet, wenn entweder eine Polling-Anfrage reinkam (d.h. 
0x8b) oder eine Antwort reinkam. Probleme habe ich dadurch noch keine 
festgestellt.

Danny Baumann schrieb:
> ... einfach weiterlaufen.

mach ich genau so ... auch keine Probleme.


//Niffko

Hallo,

mich hat die unbekannte Verschlüsselung der KM200 so genervt, dass ich 
mich ein paar Abende ans Beschnüffeln der iOS-App gemacht habe.

Mit Erfolg :)

Der Schlüssel basiert wie von Moustic beschrieben auf dem 
Gateway-Passwort und dem Benutzerpasswort, ist allerdings mit einem 
geheimen Salt versehen. Hat man diesen wird es gleich hell. 
Verschlüsselung ist AES 256 mit ECB, Padding macht die App mit PCKS#7 
und das Gateway mit Null-Bytes.

Damit alle etwas davon haben hier eine Referenzimplementierung in PHP.

Viel Spaß :)

1

// IP Adresse oder DNS-Hostname des KM200

2

define( "km200_gateway_host", '192.168.1.7', true );

3

// Gerätepasswort. Achtung: Ohne Bindestriche und in ASCII!

4

define( "km200_gateway_password", 'abcdABCDabcdABCD', true );

5

// Eigenes Passwort wie in der App vergeben

6

define( "km200_private_password", 'geheim', true );

7

// Dreh- und Angelpunkt: Der geheime Salt der MD5-Hashes zur AES-Schlüsselerzeugung

8

$MD5Salt = pack(

9

    "c*",

10

    0x86, 0x78, 0x45, 0xe9, 0x7c, 0x4e, 0x29, 0xdc,

11

    0xe5, 0x22, 0xb9, 0xa7, 0xd3, 0xa3, 0xe0, 0x7b,

12

    0x15, 0x2b, 0xff, 0xad, 0xdd, 0xbe, 0xd7, 0xf5,

13

    0xff, 0xd8, 0x42, 0xe9, 0x89, 0x5a, 0xd1, 0xe4

14

);

15

define( "km200_crypt_md5_salt", $MD5Salt, true );

16

// Erste Hälfte des Schlüssels: MD5 von ( Gerätepasswort + Salt )

17

$key_1 = md5( km200_gateway_password . km200_crypt_md5_salt, true );

18

// Zweite Hälfte des Schlüssels: MD5 von ( Salt + privates Passwort )

19

$key_2 = md5( km200_crypt_md5_salt . km200_private_password, true );

20

define( "km200_crypt_key", $key_1 . $key_2, true );

21

22

function km200_Decrypt( $decryptData )

23

{

24

  $decrypt = mcrypt_decrypt(

25

    MCRYPT_RIJNDAEL_128,

26

    km200_crypt_key,

27

    base64_decode( $decryptData ),

28

    MCRYPT_MODE_ECB,

29

    ''

30

  );

31

  // Entferne zero padding

32

  $decrypt = rtrim( $decrypt, "\x00" );

33

  // Entferne PKCS#7 padding

34

  $decrypt_len = strlen( $decrypt );

35

  $decrypt_padchar = ord( $decrypt[ $decrypt_len - 1 ] );

36

  for ( $i = 0; $i < $decrypt_padchar; $i++ )

37

  {

38

    if ( $decrypt_padchar != ord( $decrypt[$decrypt_len - $i - 1] ) )

39

      break;

40

  }

41

  if ( $i != $decrypt_padchar )

42

    return $decrypt;

43

  else

44

    return substr( $decrypt, 0, $decrypt_len - $decrypt_padchar );

45

}

46

47

function km200_GetData( $REST_URL )

48

{

49

  $options = array(

50

    'http' => array(

51

      'method' => "GET",

52

      'header' => "Accept: application/json\r\n" .

53

                  "User-Agent: TeleHeater/2.2.3\r\n"

54

    )

55

  );

56

  $context = stream_context_create( $options );

57

  return json_decode(

58

    km200_Decrypt(

59

      file_get_contents(

60

        'http://' . km200_gateway_host . $REST_URL,

61

        false,

62

        $context

63

      )

64

    )

65

  );

66

}

67

68

// Beispielaufruf

69

$REST_Service = '/system';

70

$json = km200_GetData( $REST_Service );

71

echo "Service: " . $REST_Service . "\n";

72

var_dump( $json );

Hallo Andreas
Danke für die Mühe, bei mir kommt das Ergebnis.
Service: /system object(stdClass)#1 (3) { ["id"]=> string(7) "/system" 
["type"]=> string(7) "refEnum" ["references"]=> array(6) { [0]=> 
object(stdClass)#2 (2) { ["id"]=> string(13) "/system/brand" ["uri"]=> 
string(32) "http://192.168.0.48/system/brand"; } [1]=> object(stdClass)#3 
(2) { ["id"]=> string(11) "/system/bus" ["uri"]=> string(30) 
"http://192.168.0.48/system/bus"; } [2]=> object(stdClass)#4 (2) { 
["id"]=> string(18) "/system/systemType" ["uri"]=> string(37) 
"http://192.168.0.48/system/systemType"; } [3]=> object(stdClass)#5 (2) { 
["id"]=> string(15) "/system/sensors" ["uri"]=> string(34) 
"http://192.168.0.48/system/sensors"; } [4]=> object(stdClass)#6 (2) { 
["id"]=> string(20) "/system/healthStatus" ["uri"]=> string(39) 
"http://192.168.0.48/system/healthStatus"; } [5]=> object(stdClass)#7 (2) 
{ ["id"]=> string(17) "/system/appliance" ["uri"]=> string(36) 
"http://192.168.0.48/system/appliance"; } } }

Das sagt mir leider gar nichts.

lg
Stefan

Hallo Stefan,

> Danke für die Mühe, bei mir kommt das Ergebnis.

[...]

> Das sagt mir leider gar nichts.

Das ist der Variablen-Dump des PHP-Objekts, welches vom Gateway geholt 
wurde. Es wird prinzipiell über eine REST-API mit JSON angesprochen. Im 
Beispielcoding wird der Aufruf durch die Funktion json_decode() geleitet 
und damit zum PHP-Objekt.

Im IP-Symcon-Forum gibt es auch weitere REST-URLs:
http://www.ip-symcon.de/forum/threads/25103-Buderus-Logamatic-Web-KM200

Ciao,
Andreas

Hallo,

> Voller Vorfreude habe ich Dein script dann auch direkt an meinem gateway
> probiert. Komischerweise erhalte ich nichts zurück. Ich dachte zuerst,
> dass irgendein pw nicht passt, ader das war es nicht. Mein gateway
> antwortet nur noch mit: Sorry, the requested file does not exist on this
> server. Egal welche URL (hier z.B. auf /system)

> Das war aus meiner Erinnerung mal anders. Ich bekam immer diese endlose
> kryptische json Zeichenkette.

> Ich habe dann mal den Traffic der app und dem gateway gesnifft. Die URLs
> sind gleich. Die App ruft die gleichen auf.

> Hast Du eine Idee was das sein kann?

Das sieht mir nach einem falsch gesetzten "User-Agent"-Header aus. Beim 
meiner Verbindung hatte ich "TeleHeater/2.2.3" gesnifft, das kann bei 
Dir je nach Softwarestand auch etwas anders sein. Ist die neuste App 
installiert und auf dem Gateway die neuste Firmware (Gateway ins 
Internet lassen, installiert automatisch die neuste Version)? Meine 
Firmware-Version ist 01.05.04.

Ciao,
Andreas

Hallo,

> ja ich dachte auch schon an den falschen Header. Früher hatte meine App
> den Useragent "Buderus%20iCom/2.01". Jetzt meldet sich die App auch mit
> TeleHeater/2.2.3

> Die Firmware meins Gateway ist 01.09.04
> Hardware Version iCom_Low_v1
> App Version 2.2.3

Ich habe die Hardware Version iCom_Low_NSC_v1, vielleicht daher auch der 
andere Firmware-Stand.

> Sieht so aus als hätte ich eine neuere Firmware aus Du. Gateway ist
> dauerhaft mit dem Internet verbunden. Somit sollte die auch sehr aktuell
> sein.

> Ich bekomme immer die Meldung: Sorry, the requested file does not exist
> on this server. Auch wenn ich mir einenen get request baue der die
> richtigen Header hat. Irgendwie will das Gateway nicht mehr die den
> jason request senden.

Gib dem Request mal alle Header mit die die App auch sendet, ich habe 
nur einen Teil davon eingebaut. Wichtig: Bei jedem Header die Groß- und 
Kleinschreibung beachten!

Im IP-Symcon-Forum gibt es eine Antwort die darauf schließen lässt, dass 
es mit deinem Soft- und Hardware-Stand wohl funktioniert:
http://www.ip-symcon.de/forum/threads/25103-Buderus-Logamatic-Web-KM200?p=230020#post230020

Vielleicht ist irgendwo ein Übertragungsfehler, versuch auch mal ein 
Copy&Paste von dem Coding aus dem o.g. Forum.

Ciao,
Andreas

Vielleicht kannst du mal erklären, wie das script zu nutzen ist?

wenn ich es direkt aufrufe mit php dein script läuft es durch zeigt aber 
nichts an.
ich dachte evtl muss ich dem script ein parameter übergeben wie z.b
php deinscript /system/sensors/temperatures aber auch da läuft es durch 
gibt aber keine meldung.

habe es mal mit dem html code versucht von
http://www.ip-symcon.de/forum/threads/25103-Buderus-Logamatic-Web-KM200/page4

aber dort zeigt die page nur
service value

selsbt wenn ich die Service ergänzt habe.

ich habe eine GB162 mit RC300

Egal was ich versuche,
ich bekomme immer bool(false) als meldung

Was musstest du ändern damit es bei dir lief?

Mann benötigt schon die module dazu...


sudo php5enmod mcrypt
sudo service apache2 restart

Hi Marius,
ich versuche was ähnliches mit einem ESP8266 Modul. Da meine Platine - 
im Prinzip der reine EMS - RxTx Konverter von Ingo/Niffko - noch nicht 
fertig ist, dauert das allerdings noch ein wenig.
Die Platine hat einen Bestückungsplatz für ein ESP01-Modul sowie eine 
Arduino-kompatible FTDI Steckerleiste (J1).
Bei Interesse gibste einfach Bescheid.

Hallo Jungs,

toller Thread zum Thema, der mir endlich ermöglichen wird, meine
Heizung (GB162/15 mit RC35) vernünftig fernzusteuern und die
Einbindung des solaren Überschusses in die Heizung optimal
gestalten zu können!

1.)
Hat schon mal jemand herausgefunden mit welchen Funtionen
das Störmeldemodul EM10 den Brenner fernsteuert ?
Mich interessiert insbesondere die Leistungs- bzw. Temperatur-
anforderung.

2.)
Wie funktioniert dabei das Zusammenspiel mit einer
evt. parallel vorhanden Steuerung z.B. einer RC35 ?
Damit meine ich das Problem, das es bei gleichzeitigem Vorhandensein
eines EM10 und einer RC35 prinzipiell 2 unterschiedliche 
Wärmeanforderungen
an den Kessel im System gibt.
Wie funktioniert das dann? Wer hat Vorrang?

Grüße
Stefan aus Berlin

Hallo,

arbeitet noch jemand am Reverse der aktuellen EMS-Protokollbestandteile 
z. B. der RC300? Ich meine alle bisher unbekannten Messages.

Ich habe mal einige Dinge geloggt und bin dabei mich mit einigen Lines 
vom Typ 0xff zu beschäftigen. Z. B. habe ich ein paar Werte gefunden, 
welche die RC300 beim Ändern von Auto in Manuell ändert. (Kessel-Soll 
und eingestellte Raumtemp.)

Um nichts doppelt zu machen: hat schon jemand Fortschritte mit diesen 
Telegrammen gedacht?

Ich hoffe, der Thread wird zu diesem Zweck noch benutzt...

Gruß
Fabian

Hallo Ingo,

danke für die "Vorarbeit". Da ich die Daten in Access einlese um sie 
schneller auszuwerten zu können, habe ich erst mal ein paar Änderungen 
an den Modulen EmsMessage.cpp und IoHandler.cpp gemacht.

Ziel war die einheitliche Anzeige von raw IO-Bytes und Messages. 
Außerdem habe ich die hex-Anzeige der IO-Bytes ergänzt (z. B. aus 00 
wird 0x00 und aus 0x2 wird 0x02, dann lassen sich Zeilen direkt 
untereinander legen) und einen TimeStamp wie bei Messages hinzugefügt.
Vorher sah die Anzeige so aus:

1

IO: Got bytes 0xaa 0x55 0x11 0x8 00 0x7 00 0xb 0x1 00 00 00 00 00 00 0x1 00 00 00 00 0x4 

2

MESSAGE[14.10.2014 15:48:13]: source 0x08, dest 0x00, type 0x07, offset 0, data: 0x0b 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00

Damit man die raw Bytes besser vergleichen und zeitlich korrekt zuordnen 
kann, jetzt diese Formatierung:

1

IOBytes[22.10.2014 15:52:54]: 0xaa  0x55  0x08  0x10  0x00  0xff  0x00  0x01  0x67  0x00  0x00  0x89 

2

MESSAGE[22.10.2014 15:52:55]: source 0x10, dest 0x00, type 0xff, size 0x08, offset 0, data: 0x01 0x67 0x00 0x00

Ach so, die Länge (size) habe ich mit eingefügt. Bei den Messages mit 
Typ 0xff gibt es verschiedene Längen, welche jeweils zusammengehören. 
Daher nimmt die eindeutige Länge vorerst eine Art virtuellen Typ des 
Telegramms ein.

Wenn jemand eine bessere Idee hat, ich bin für alles offen... ;)

Grüße
Fabian

Hallo,

könnte jemand mal einen Mitschnitt eines EmsPlus Systems posten. Im 
Speziellen interessieren mich Anfragen an den RC300.

Ich habe an meinem EMS System einen RC300 montiert und bin auf der Suche 
nach der Raumtemperatur. Wie es aussieht, werde ich die aktiv abfragen 
müssen.

Besten Dank im Voraus!


//Niffko

@Andy:
An sich hast Du recht, bei gleichen Pegeln wäre der Widerstand nicht 
notwendig. Aber oft koppelt man solche Systeme mit Widerständen, sog. 
Line-Widerständen. In dieser Hinsicht war ich auch über den Eingang an 
Pin6 ohne diesen Linewiderstand verwundert. Aber sicher entstammt das 
dem ursprünglichen Schaltplan...

@Niffko
Ich zeichne seit gut zwei Wochen alle Daten wie oben beschrieben auf. 
Alle paar Tage beginne ich ein neues File. Wie viel willst Du haben und 
wie soll ich es Dir zu senden? Ich bin leider wegen anderer Baumaßnahmen 
noch nicht zum Auswerten gekommen.
Ich steuere den Ofen derzeit behelfsmäßig über das eingebaute KM50. Da 
sollte folglich einiges in Richtung RC300 dabei sein.
Leider antwortet das Modul oft nicht und hängt sich ca. einmal die Woche 
komplett auf. Da hilft nur Stecker ziehen. Werde ich bei Gelegenheit mal 
bei Buderus reklamieren.

Gruß
Fabian

Hallo!

R5 soll warscheinlich die IC's schüzten, falls der Ausgang vom uC auch 
auf Output geschaltet ist und beide Ausgänge dann gegeneinander 
arbeiten.

Jürgen

Hier mal ein Tages-Log vom 03.11. als zip
Gruß Fabian

Jürgen Schmied schrieb:
> falls der Ausgang vom uC auch
> auf Output geschaltet ist und beide Ausgänge dann gegeneinander
> arbeiten

Das sollte exakt die Erklärung sein. Ich hatte vergessen, auf den 
Schutz-Charakter der Rs hinzuweisen. Jürgen hat es auf den Punkt 
gebracht. Danke!

Gruß Fabian

Hab' was Neues zum Thema EmsPlus (zumindest habe ich es noch nirgends 
gelesen). Danke an Fabian für die Log-Daten!

Es betrifft die Telegramme vom Typ "FF", die mit EmsPlus aufgetaucht 
sind.

"FF" ist hier weniger der Telegrammtyp als vielmehr eine Art Marker für 
ein Telegramm mit erweitertem Typenumfang (16Bit).

Und da ein Beispiel mehr als 1000 Worte sagt ...

Anfrage: 0B 90 FF 00 0A 01 B9 CRC

0B    Sender
90    Empfänger
FF    Marker EmsPlus
00    Offset
0A    Anzahl Bytes
01B9  Telegramm Typ



Antwort: 10 0B FF 00 01 B9 Data CRC

10    Sender
0B    Empfänger
FF    Marker EmsPlus
00    Offset
01B9  Telegramm Typ


In Fabians Log gibt es noch Telegramme vom "Typ" F6, F7 und F9, bei 
denen es sich anscheinend auch um den neuartigen Telegrammtyp handelt.



//Niffko

Hallo Niffko,

ich hatte diese Entdeckung auch bereits gemacht, war mir jedoch nicht 
sicher, daher die Einstufung vorerst nach der Länge. Hier mal eine kurze 
Gruppierung in Access:

S1  Source  Dest  Typ  Offs  T1  T2  B7  B8  B9
0x08  0x10  0x00  0xff  0x08  0x01  0xa5  0x00  0x10  0x53
0x08  0x10  0x00  0xff  0x06  0x01  0xa5  0x2c  0x1e  0x7f
0x08  0x10  0x00  0xff  0x08  0x01  0xa5  0x00  0x0b  0x48
0x08  0x10  0x00  0xff  0x08  0x01  0xa5  0x05  0xa0  0xe6
0x08  0x10  0x00  0xff  0x06  0x01  0xa5  0x2f  0x2f  0x4d
0x08  0x10  0x00  0xff  0x08  0x01  0xa5  0x00  0x0b  0x48
0x08  0x10  0x00  0xff  0x06  0x01  0xa5  0x2c  0x1e  0x7f
0x08  0x10  0x00  0xff  0x06  0x01  0xa5  0x2f  0x2f  0x4d
0x08  0x10  0x00  0xff  0x08  0x01  0xa5  0x05  0xa0  0xe6
0x08  0x10  0x00  0xff  0x00  0x01  0x67  0x00  0x00  0x89

das sind Werte die innerhalb weniger Minuten geloggt wurden. Der letzte 
fällt bei gleicher Länge in diesem Beispiel aus der Reihe.
Aus obiger Reihe (demnach vom Typ 0xFF 0x01 0xa5) habe ich bereits zwei 
Werte vom RC300 identifizieren können (hier ohne Trailer 0xaa 0x55):
0x1f 0x10 0x00 0xff 0x00 0x01 0xa5 0x80 0x00 0x01 0x2c 0x21 0x00 
0x2c 0x1e 0x00 0x8e 0x03 0x03 0x01 0x00 0x8e 0x00 0x53 0x00 0x00 0x11 
0x01 0x03 0xff 0xff 0x00 0xb4
und
0x1f 0x10 0x00 0xff 0x00 0x01 0xa5 0x80 0x00 0x01 0x2f 0x21 0x00 
0x2f 0x2f 0x05 0xa0 0x02 0x03 0x01 0x00 0x8d 0x00 0x54 0x00 0x00 0x11 
0x01 0x02 0xff 0xff 0x00 0xaa

Ich habe die Raum-Soll-Temp. von 22,0° (0x2c) auf 23,5° (0x2f) geändert 
und dabei hat sich die Vorlauf Solltemperatur von 33° (0x21) auf 37° 
(0x25) geändert. Das ist eindeutig, habe es mehrfach auch mit anderen 
Werten getestet. Die Raumtemp. scheint in zwei Spalten zu stehen. Keine 
Ahnung warum.

Nicht viel, aber ein Anfang...

Gruß Fabian

Hallo Ingo,

IngoF schrieb:
>
> Wer ist den 0x48?
>
ich hatte weiter oben beschrieben, dass ich über das eingebaute KM50 auf 
die Regelung des Ofens mittels REST-Api zugreife. Folglich sollten dort 
Informationen ausgetauscht werden.

Übrigens: ich sende zum Aktivieren des Ofens 22° und zum deaktivieren 
15° als temporäre Temperatur (wie beim manuellen Ändern der 
eingestellten Temperatur im auto-Modus). Auch das sollte sich finden 
lassen.

Gruß Fabian

Hallo zusammen,

ich habe auf dem EMS+ ein paar Daten identifiziert:

Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureRoomSetpoint
Antwort:
10 f9 00 ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a

Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2:
0a: min:    5°C
2a: ???:   21°C?
3c: max:   30°C
2a: value: 21°C

Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/eco
Antwort:
10 f9 00 ff 01 b9 04 1f 00 00 00 0a 00 00 00 1e 00 00 00 2d 00 00 00 22

Wieder Faktor 2:
0a: min:    5,0°C
1e: ???:   15,0°C?
2d: max:   22,5°C
22: value: 17,0°C

Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/comfort2
Antwort:
10 f9 00 ff 01 b9 02 0f 00 00 00 23 00 00 00 2a 00 00 00 3c 00 00 00 2e

Wieder Faktor 2:
23: min:   17,5°C
2a: ???:   21,0°C?
3c: max:   30,0°C
2e: value: 23,0°C

Abfrage auf dem KM200: /heatingCircuits/hc1/fastHeatupFactor
Antwort:
10 f9 00 ff 01 af 0a 17 00 00 00 01 00 00 00 00 00 00 00 64 00 00 00 00

Diesmal Faktor 1:
01: min:    1%
00: ???:    0%?
64: max:  100%
00: value:  0%

Ich vermute mal, dass die 3x 00 vor den Daten für hk4...hk2 reserviert 
sind.

Grüße, Torsten

IngoF schrieb:
> I suppose the Counters are still at zero because the are no
> "framing-bytes" (aa 55).

You're confusing EMS UART data with preprocessed data. There's no 0xaa 
0x55 to be expected on the EMS, and the NET IO outputs its data via LAN, 
not UART ;)

Still, this looks like invalid data, so something is probably wrong in 
the hardware.

IngoF schrieb:
> IngoF schrieb:
>> Danny Baumann schrieb:
>>> You're confusing EMS UART data with preprocessed data.
>>
>> Das stimmt..
>>
>> Warum zählt denn "Bytes total:0" nicht hoch? sind das nur die Bytes der
>> Fehlerfreien Telgramme? Hätte jetzt vermutet die kompletten Empfangenen
>> Bytes.
>
> Ups manchmal könnte denken helfen ;-)
>
> Der NetIO schickt ja nur Fehlerfreie Telegramme weiter. Also kann Dein
> Collector ja nichts hochzählen was er nciht bekommt..

Richtig. Die Anzeige kommt allerdings vom NET IO, was fehlerhafte Daten 
durchaus zählt ;) Ich nehme mal an, dass das NET IO schon gar kein 
Framing (d.h. Breaks) sieht und deshalb gar nicht erst anfängt, die 
Daten zu interpretieren.

Are you using the 3.5mm service connector for connection? If yes: don't, 
but use the normal EMS bus connectors (where other modules and/or RC35 
are connected)

Hi,

Maarten H schrieb:
> I see no framing start (aa 55) however I see a lot of "3F"

perhaps a timing issue.
are the fuses in the right order?

(e7) Fuse Low Byte (FLB)
(dc) Fuse High Byte (FHB)
(ff) Extended Fuse Byte (EFB)

Greets
Karl M.

IngoF schrieb:
> Torsten Georg schrieb:
>> 10 f9 00 ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a
>
> Hallo Thorsten,
> Sind das die ganzen Telegramme oder nur die Nutzlast?
> Wenn ich es richtig verstanden habe sollte nach dem 0xff als Datentyp
> erst die Länge und dann ein 16-Bit Telegrammtyp kommen?
>
> Gruß
> IngoF

Hallo Ingo,

ich war ein paar Tage unterwegs. Daher erst jetzt meine Antwort.

Du hast natürlich recht. Ich habe da etwas unterschlagen. Ich habe im 
Log nur die "MESSAGE"" aktiviert, da ich dabei die Uhrzeiten mit der 
KM200 Abfrage einfacher vergleichen konnte.

Hier die korrigierte Version:

Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureRoomSetpoint
Antwort:
MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a

Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2:
0a: min:    5°C
2a: ???:   21°C?
3c: max:   30°C
2a: value: 21°C

Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/eco
Antwort:
MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
data: ff 01 b9 04 1f 00 00 00 0a 00 00 00 1e 00 00 00 2d 00 00 00 22

Wieder Faktor 2:
0a: min:    5,0°C
1e: ???:   15,0°C?
2d: max:   22,5°C
22: value: 17,0°C

Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureLevel/comfort2
Antwort:
MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
data: ff 01 b9 02 0f 00 00 00 23 00 00 00 2a 00 00 00 3c 00 00 00 2e

Wieder Faktor 2:
23: min:   17,5°C
2a: ???:   21,0°C?
3c: max:   30,0°C
2e: value: 23,0°C

Abfrage auf dem KM200: /heatingCircuits/hc1/fastHeatupFactor
Antwort:
MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
data: ff 01 af 0a 17 00 00 00 01 00 00 00 00 00 00 00 64 00 00 00 00

Diesmal Faktor 1:
01: min:    1%
00: ???:    0%?
64: max:  100%
00: value:  0%

Ich vermute mal, dass die 3x 00 vor den Daten für hk4...hk2 reserviert 
sind.

Grüße, Torsten

Hallo Torsten,

Torsten Georg schrieb:
> Du hast natürlich recht. Ich habe da etwas unterschlagen. Ich habe im
> Log nur die "MESSAGE"" aktiviert, da ich dabei die Uhrzeiten mit der
> KM200 Abfrage einfacher vergleichen konnte.

genau deswegen habe ich den EMS-Collector modifiziert. Damit findet sich 
in beiden Infos (Message und IO-Bytes) die Zeit, außerdem hatte ich die 
Größe noch extra aufbereitet, da man die EMS+ Messages damit erst mal 
grundsätzlich ordnen kann.
Siehe mein Log-File im Post weiter oben.

Wenn Interesse besteht und von offizieller Seite (Andi und Danny) nichts 
dagegen spricht, kann ich die beiden geänderten Quelldateien hier 
veröffentlichen.

Gruß Fabian

Moin zusammen,
da mir noch die Anzeige der Raumtemp. fehlt und ich nur ein RC200 zu 
meiner GW172-24 besitze, ist hier vermutlich auch noch ein wenig reverse 
nötig. Da ich nur 0x08 und 0x18 als source finde, gehe ich mal davon 
aus, dass 0x18 mein RC200 ist.

Hier mal ein kleiner Auszug:

1

 MESSAGE[14.12.2014 18:57:35]: source 0x18, dest 0x00, type 0xff, offset 0, data: 0x01 0xa5 0x00 0xdf 0x21 0x2b 0x2a 0x00 0x2b 0x20 0x00 0xf4 0x03 0x03 0x01 0x00 0xf4 0x02 0x90 0x00 0x00 0x11 0x01 0x03 0x08 0xb9 0x00

2

MESSAGE[14.12.2014 18:57:36]: source 0x18, dest 0x00, type 0xff, offset 25, data: 0x01 0xa5 0x00 0x04 0xff 0xe2 0x00 0x00 0x00 0x64 0x4b 0x00 0x3c 0x01 0xff

3

MESSAGE[14.12.2014 18:57:36]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64

4

MESSAGE[14.12.2014 18:57:51]: source 0x18, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x00 0xf3 0x02 0x91

5

MESSAGE[14.12.2014 18:58:20]: source 0x18, dest 0x00, type 0x06, offset 0, data: 0x0e 0x0c 0x12 0x0e 0x39 0x1e 0x06 0x00 0x18 0x00 0x00

6

MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x00, type 0xff, offset 0, data: 0x01 0xa5 0x00 0xdf 0x21 0x2b 0x2a 0x00 0x2b 0x20 0x00 0xf3 0x03 0x03 0x01 0x00 0xf3 0x02 0x91 0x00 0x00 0x11 0x01 0x03 0x08 0xb9 0x00

7

MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x00, type 0xff, offset 25, data: 0x01 0xa5 0x00 0x04 0xff 0xe2 0x00 0x00 0x00 0x64 0x4b 0x00 0x3c 0x01 0xff

8

MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64

9

MESSAGE[14.12.2014 18:58:50]: source 0x18, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x00 0xf2 0x02 0x92

10

MESSAGE[14.12.2014 18:59:20]: source 0x18, dest 0x00, type 0x06, offset 0, data: 0x0e 0x0c 0x12 0x0e 0x3a 0x1e 0x06 0x00 0x18 0x00 0x00

11

MESSAGE[14.12.2014 18:59:34]: source 0x18, dest 0x00, type 0xff, offset 0, data: 0x01 0xa5 0x00 0xdf 0x21 0x2b 0x2a 0x00 0x2b 0x20 0x00 0xf2 0x03 0x03 0x01 0x00 0xf2 0x02 0x92 0x00 0x00 0x11 0x01 0x03 0x08 0xb9 0x00

12

MESSAGE[14.12.2014 18:59:34]: source 0x18, dest 0x00, type 0xff, offset 25, data: 0x01 0xa5 0x00 0x04 0xff 0xe2 0x00 0x00 0x00 0x64 0x4b 0x00 0x3c 0x01 0xff

13

MESSAGE[14.12.2014 18:59:34]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64

Auch hier sind die "ff" Telegramme ähnlich wie bei Fabian. Raum Soll 
0x2b passt. Leider finde ich aber die aktuelle Raumtemp. von 22,0 Grad 
nicht darin (vielleicht bin ich auch zu blind). Hat jemand eine Idee?

@Frank S.
Ich habe hier eine Mischinstallation GB142(EMS) + RC300(EMS+). Somit ist 
das Folgende etwas mit Vorsicht zu genießen.

Unter EMS+ wird die Raumtemperatur offensichtlich nicht mehr ungefragt 
auf dem Bus bereitgestellt. Sie muss aktiv abgefragt werden.

Versuche mal, ob du eine Antwort bekommst, wenn du vom RC200 Telegramm 
0xFF Subtype 0x0139 abfragst.


//Niffko

Hallo Danny,

vlt. willst Du folgendes in Deinen Collectord einbauen:

// add Warmwasserdurchfluß
// Buderus GB162-25 T40S
// ---
Database.cpp
   query.execute(SensorWarmwasserDurchfluss, sensorTypeNumeric,
  "Warmwasserdurchfluss", readingTypeVolume, "l/min", 1);
Database.h
  SensorWarmwasserDurchfluss = 26,
    static const unsigned int readingTypeVolume = 7;
EMSMessage.cpp
   printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min",
  Database::SensorWarmwasserDurchfluss);
www/ems/constants.php.inc
   define('SensorWarmwasserDurchfluss', 26);
   define('ReadingTypeVolume', 7);
// ---

... dann können die Jungs und Mädels, die einen GB162-25 T40S ihr Eigen 
nennen, den Warmwasserdurchfluß ihres Boilers ablesen, zB. mit:

www/ems.php
   print_cell("WW-Durchfluß", $sensors[SensorWarmwasserDurchfluss]);

tia'n greets
Karl M.

Charlie W. schrieb:
> EMSMessage.cpp
>    printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min",
>   Database::SensorWarmwasserDurchfluss);

... uuups, da habe ich wohl ein paar Änderungen vom 17.02.2014 
verschlafen. :-*) So sorry!

Karl M.

Charlie W. schrieb:
> Charlie W. schrieb:
>> EMSMessage.cpp
>>    printNumberAndAddToDb(10, 1, 10, "Warmwasserdurchfluss", " l/min",
>>   Database::SensorWarmwasserDurchfluss);
>
> ... uuups, da habe ich wohl ein paar Änderungen vom 17.02.2014
> verschlafen. :-*) So sorry!

Da komme ich jetzt nicht mit. Warmwasserdurchfluss habe ich nicht 
implementiert, und Moosy AFAIK auch nicht. Wo siehst du das in meinem 
Code? (Und wenn es nicht drin ist: In welchem Telegramm steht das?)

Sers Danny,

Danny Baumann schrieb:
> Und wenn es nicht drin ist:

Ist "noch" nicht drin. ;-)

> In welchem Telegramm steht das?

UBAMonitorWWMessage
Quelle  Ziel  Typ  Start  Bit  Bytes  Divisor  Linie  Einheit
08  00  34  14    1  10  analog  l/min

Hatte das für mich mal eingepflegt - vor der Änderung am 17.02.2014 - 
und dann wieder vergessen. Jetzt wollte ich es wieder einpflegen und 
merke, Du hast den Code deutlich umstrukturiert. Sorry, ich hatte vorher 
nicht drauf geschaut.

Wäre natürlich super, wenn Du es einbauen könntest.

Gruß
Karl M.

Charlie W. schrieb:
> UBAMonitorWWMessage
> Quelle  Ziel  Typ  Start  Bit  Bytes  Divisor  Linie  Einheit
> 08  00  34  14    1  10  analog  l/min

Danke.

> Wäre natürlich super, wenn Du es einbauen könntest.

Kann und werde ich tun. Muss es auch in die Datenbank mit rein? Wenn ich 
mich recht entsinne, verwendet doch Moosy's Frontend jetzt den Live-Feed 
(auf Port 7778) und/oder die Abfragemöglichkeit per Kommando (cache 
fetch...), oder?

EDIT: Probier mal das, was ich gerade eingecheckt habe :)

Danny Baumann schrieb:
> Muss es auch in die Datenbank mit rein?

Jepp!
Habe ich damals, 12.2013, bei mir händisch hinzugefügt.

> Wenn ich
> mich recht entsinne, verwendet doch Moosy's Frontend jetzt den Live-Feed
> (auf Port 7778) und/oder die Abfragemöglichkeit per Kommando (cache
> fetch...), oder?

So sehe ich das auch.

> Probier mal das, was ich gerade eingecheckt habe :)

Herzlichen Dank! Werde ich tun, ich melde mich dann.

Niffko _ schrieb:
> Versuche mal, ob du eine Antwort bekommst, wenn du vom RC200 Telegramm
> 0xFF Subtype 0x0139 abfragst.

Ich bin mir nicht sicher, ob die Abfrage korrekt ist:
raw read 0x18 0xff 0x01 0x39 0 25

Dabei kommt nur ein "OK"

edit:

Output ist der folgende:
source 0x18, dest 0x0b, type 0xff, offset 1, data: 0xf8 0xbc

aktuelle Temp ist 22,5 Grad

und ein "raw read 0x18 0xff 0 25"
ergibt :
source 0x18, dest 0x0b, type 0xff, offset 0, data: 0xda 0x64

Hi Danny,

Danny Baumann schrieb:
> Probier mal das, was ich gerade eingecheckt habe :)

Perfekt, hat auf Anhieb geklappt!

Dann noch folgendes nachtragen in:
www/ems/constants.php.inc
   define('SensorWarmwasserDurchfluss', 26);
   define('ReadingTypeFlowRate', 7);

und in:
www/ems/lemscnt.ajax
   ...
   print ... $d["ww flowrate"]." l/min" ...
   ...

und schon klappts auch mit Moosys Frontend.

Bedankt und Gruß
Karl M.

@Frank
Orientiere dich an meinem 
Beitrag "Re: Faktensammlung Buderus EMS"

Davon ausgehend, dass 0x18 dein RC200 ist, müsste die Anfrage auf dem 
Bus so aussehen: 0B 98 FF 00 FF 01 39 CRC

Ob das Dannys Code so auf den Bus bzw. geparst kriegt, weiß ich nicht.


//Niffko

Niffko _ schrieb:
> "FF" ist hier weniger der Telegrammtyp als vielmehr eine Art Marker für
> ein Telegramm mit erweitertem Typenumfang (16Bit).
>
> Und da ein Beispiel mehr als 1000 Worte sagt ...
>
> Anfrage: 0B 90 FF 00 0A 01 B9 CRC
>
> 0B    Sender
> 90    Empfänger
> FF    Marker EmsPlus
> 00    Offset
> 0A    Anzahl Bytes
> 01B9  Telegramm Typ

Torsten Georg schrieb:
> Hier die korrigierte Version:
>
> Abfrage auf dem KM200: /heatingCircuits/hc1/temperatureRoomSetpoint
> Antwort:
> MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
> data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a
>
> Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2:
> 0a: min:    5°C
> 2a: ???:   21°C?
> 3c: max:   30°C
> 2a: value: 21°C

Hallo,

ich habe das mal so "verstanden":
MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a

KM200: /heatingCircuits/hc1/temperatureRoomSetpoint
Die Daten finden sich jeweils nach den 3x 00 mit Faktor 2:
Sender  0x10
Empfänger  0x48
EMS-Plus  0xf9
Offset  0x00
Typ    0x01b9
??     0x0a
??     0x13
12  0a: min:    5°C
16   2a: ???:   21°C?
20  3c: max:   30°C
24  2a: value: 21°C

/heatingCircuits/hc1/temperatureLevel/eco
Wieder Faktor 2:
Sender  0x10
Empfänger  0x48
EMS-Plus  0xf9
Offset  0x00
Typ    0x01b9
??     0x04
??     0x1f
12  0a: min:    5,0°C
16  1e: ???:   15,0°C?
20  2d: max:   22,5°C
24  22: value: 17,0°C

KM200: /heatingCircuits/hc1/temperatureLevel/comfort2
Wieder Faktor 2:
Sender  0x10
Empfänger  0x48
EMS-Plus  0xf9
Offset  0x00
Typ    0x01b9
??     0x02
??     0x0f
12  23: min:   17,5°C
16  2a: ???:   21,0°C?
20  3c: max:   30,0°C
24  2e: value: 23,0°C

KM200: /heatingCircuits/hc1/fastHeatupFactor
Diesmal Faktor 1:
Sender  0x10
Empfänger  0x48
EMS-Plus  0xf9
Offset  0x00
Typ    0x01af
??     0x0a
??     0x17
12  01: min:    1%
16  00: ???:    0%?
20  64: max:  100%
24  00: value:  0%

Was mich dann wundert ist dass die ersten 3 Beispiele das selbe 
Telegramme mit dem selben Offset ist. Ist das erste Byte der Daten ein 
weiteres Offset?? Oder gilt das alte Offste nicht mehr? Hat jemand eine 
Idee?

habe erst mal einiges im Wiki zu EMS-Plus versucht umzustricken...

Ingo F. schrieb:
> ich habe das mal so "verstanden":
> MESSAGE[...]: source 0x10, dest 0x48, type 0xf9, offset 0,
> data: ff 01 b9 0a 13 00 00 00 0a 00 00 00 2a 00 00 00 3c 00 00 00 2a

Was mich bei den Telegrammen irgendwie stört, ist das "FF" zwischen 
Offset und Subtype.

Wenn mein RC300 antwortet, würde das so aussehen:
10 48 F9 00 01 B9 XX XX ...


Dass bei den ersten 3 Beispielen Typ und Offset gleich sind, liegt denke 
ich daran, dass die vom KM200 abgefragten 3 Parameter im gleichen 
Telegramm enthalten sind. Dieses erscheint dann natürlich bei jeder 
einzelnen Abfrage auf dem Bus. Ich vermute, dass die Sollwerte zwischen 
den Abfragen geändert wurden.



//Niffko