Faktensammlung Buderus EMS

[Danny B. (maniac103)]

Da die alten Threads ja inzwischen ziemlich unübersichtlich geworden 
sind, möchte ich mal einen neuen Thread zum EMS aufmachen. Dieses 
Posting dient dabei gleich als Linksammlung die wichtigsten 
Informationen. Wenn jemand Linkvorschläge hat, nur zu :)

Hardware-Schaltpläne:
- Original-Schaltung, getestet, reverse engineered von Niffko
  Beitrag "Re: Logamatic 2107 Schnittstelle"

Software:
- EMS-Collector (C++-Daemon, der EMS-Daten auswertet und in MySQL 
schreibt; erlaubt auch Steuerung)
  http://github.com/maniac103/ems-collector
- Ethersex (AVR-Firmware, kann EMS auf TCP umsetzen)
  http://github.com/ethersex/ethersex

Doku zum Telegrammaufbau:
- Wiki
  http://ems-gateway.myds.me/dokuwiki/
- EMS-Collector-Quellcode (siehe oben)
- Java-Quellcode von Jürgen Schmied
  Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung"

Bestehende Threads mit Informationen:
- alter Thread
  Beitrag "Logamatic 2107 Schnittstelle"
- EMS-Gateway-Thread von Ingo F.
  Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung"

[Ra S. (mcfloppy)]

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

[Ra S. (mcfloppy)]

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.

[Jürgen S. (Firma: privat) (jschmied)]

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

[Ra S. (mcfloppy)]

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?

[Jürgen S. (Firma: privat) (jschmied)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

vg

Jürgen

[Niffko _. (niffko)]

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

[Danny B. (maniac103)]

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 ;)

[Danny B. (maniac103)]

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.

[Jürgen S. (Firma: privat) (jschmied)]

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 !?

[Danny B. (maniac103)]

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

[Ra S. (mcfloppy)]

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

[Ra S. (mcfloppy)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[Ra S. (mcfloppy)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[Ra S. (mcfloppy)]

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

[Danny B. (maniac103)]

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?!

[Ra S. (mcfloppy)]

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

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

[Danny B. (maniac103)]

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.

[Ra S. (mcfloppy)]

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

[Danny B. (maniac103)]

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.

[Ra S. (mcfloppy)]

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

[Danny B. (maniac103)]

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?

[Ra S. (mcfloppy)]

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 ;)

[Rudi (Gast)]

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

Kannst du mal schauen ob du eines von den DEBUG-Befehlen rausnehmen 
kannst? Da ist definitiv noch etwas am Timing nicht richtig.

[Jürgen S. (Firma: privat) (jschmied)]

Hallo!

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

vg

Jürgen

[Jürgen S. (Firma: privat) (jschmied)]

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

[Stefan M. (stefan-muehlbauer)]

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

[Danny B. (maniac103)]

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

[Stefan M. (stefan-muehlbauer)]

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

lg
Stefan

[Danny B. (maniac103)]

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...

[Jester (Gast)]

Guten Tag,

Ich wollte eine unsere Logamatic 2107M über eine RC35 ansteuern, wozu 
eine Art Konverter zwischengeschaltet werden muss.

Nachdem ich diesen Thread quasi ganz durchgelsen habe, blicke ich nicht 
mehr ganz durch. :(

Die wichtigste Frage
- Beinhaltet dieses EMS-Gateway den Konverter den ich benötige?

"Beifang"
- Wenn ja, kannt das Gateway gleichzeitig eine Ansteuerung über LAN 
bereitstellen?

Ich bedanke mich in Vorfeld für die Informationen.

[Jürgen S. (Firma: privat) (jschmied)]

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

[Jester (Gast)]

Danke! :)

[Alex A. (alexander_amend)]

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

[Alex A. (alexander_amend)]

Hier nochmal 2 Bilder

[Jürgen S. (Firma: privat) (jschmied)]

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

[Alex A. (alexander_amend)]

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

[Alex A. (alexander_amend)]

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!).

[F. F. (pic18f)]

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.

[Jürgen S. (Firma: privat) (jschmied)]

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

[Ingo F. (ingof)]

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

[Ingo F. (ingof)]

Da war Jürgen wohl schneller...

Jürgen Schmied schrieb:
> Warmwasser

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[F. F. (pic18f)]

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.

[Danny B. (maniac103)]

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?

[F. F. (pic18f)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[IngoF (Gast)]

F. F. schrieb:
> Im Wiki habe ich nur die Urlaubszeiten (Typ 0x3f)

Das sind auch die Schaltzeiten. Die Urlaubsfunktion ist ab Offset 0x57
Die Urlaubsfunktion kann man mit 0b 10 3f 57 06 <Prüfsumme> von 
Heizkreis 1 abfragen. Die Schaltzeiten sind im ganzen Bereich vor der 
Urlaubsfunktion.

Jürgen Schmied schrieb:
> 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.

Hast Du denn schon mal probiert die Zeiten zu ändern? Denke schon dass 
die RC30/RC35 das akzeptiert.

Die Uralubsfunktion konnte ich schon erfolgreich über mein Java-Programm 
ändern. Allerdings hatte ich die Urlaubsfunktion nicht für Warmwasser 
und Zirkulation gefunden.

Beim Einschalten der Urlaubsfunktion wurden wohl nur die 
Schaltzeiten-Telegramme für die Heizkreise gesendet. Für Warmwasser und 
Zirkulation habe cih damals keine Telegramme auf dem Bus gesehen.

F. F. schrieb:
> Wenn ich das
> Schaltprogramm an der RC30 ändere, werden diese Daten dann auf den
> EMS-Bus sofort gesendet?

Bin zwar nicht Danny, Aber wenn man die Schaltzeiten an der RC30 ändert 
werden diese dann in mehreren Teilen übertragen.


Gruß
Ingo

[Kevin Heidrich (Gast)]

Alex Amend schrieb:
> 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.

ich habe mir mal dein Log angeschaut, und so wie es scheint geht die 
Kommunikation über HTTP/80 per Binary JSON.

-----

HTTP/1.0 200 The request has succeeded
Content-Type: application/json


veSJNc+lFfrdObDjj04tWC+pGbZELyzUiQaSZli48U+ax2nFuLmVP6m9X7M/PtRmDZc/PngS 
6VF+9Pj8OG1XIj+7oCNQV9vAp0fGL9gboUhh8XdfqOcQbkH6eu1RzHJ1H/6mdPjM2ielVRed 
TgYvvfhOeldH64YiUN8bfnu3cjPxSn1zR5y82nSQszQ2kK7/oRaBNHJaJ1xkVXpl1y8KQrT8 
IfzTrW356VeTa+inpSehjHXp6aiiD21SDCQPBHexaNq+MMb3ZjCppyNTUhKxspybIEuNRNYP 
NEF7R/SF6rAewrwo1cLzsSB22pKqrXjxPSIbEWDCGTJDKY8suxLT5u+Dv74hIHsg0xc3fo1q 
PhEf4x5XbfveedsRqPMi+ePSQr1pEkkKyYkEkksXKEHoYk4TFKaWQSdi7yilgfc/0LJKW5cp 
jlnqppMN5ZIvKFZyL4Cc+Tl8CBVHbj2oBxPw/V2GnLFpvBoKAC9DZiNiBCLnSp+bI99TozqR 
oalkC9H/SakHzT3hN3vMpLhj/qCOiQs6+CA968AYE0qwO80pLRPi+JTsCM0oB+ecPePkiUQq 
v4m5wtVuPAUXM6Px109+VPhOeldH64YiUN8bfnu3cjOS665LPoIv0JnQrdQcebJMoRaBNHJa 
J1xkVXpl1y8KQrT8IfzTrW356VeTa+inpScIiqy5T3fgAcy3RxT42S0r

----

Das ganze ist dann noch Base64 kodiert. Das Endergebnis ist dann 
allerdings wiederum ernüchternd. Nichts was man so lesen könnte. Ich 
dachte es wäre evtl. am Ende dann doch wieder JSON, aber da komme ich 
nicht weiter.

Gruß
Kevin

[Jürgen S. (Firma: privat) (jschmied)]

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

js

[Danny B. (maniac103)]

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.

[Jürgen S. (Firma: privat) (jschmied)]

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

[Danny B. (maniac103)]

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.

[Jürgen S. (Firma: privat) (jschmied)]

Hallo!

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

vg

Jürgen

[F. F. (pic18f)]

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

[KArl (Gast)]

Danny Baumann schrieb:
> 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.

Bei WW ist die Leistung max. 125%.

>> 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.

Bei der Umschaltung der Heizkreise kann der Brenner schon ausgehen und 
in der Übergangszeit ist es eh am schlimmsten mit den Brennerstarts. Das 
gibt sich dann wieder im Winter wenn es gut kalt ist oder im Sommer wenn 
nur WW bereitet wird.


---

[Karl M. W. (charlie-w)]

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

[Norbert S. (norbert)]

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

[giovanne (Gast)]

Hi,

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.
Dadurch konnte ich die Starts erheblich senken und habe bisher keinen 
Komfort einbüsen müssen ;-)

Grüße
giovanne

[Danny B. (maniac103)]

> 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?

[Karl M. W. (charlie-w)]

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.

[Norbert S. (norbert)]

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

[niffko (Gast)]

Taktsperre ist auch in der 2.Bedienebene nicht einstellbar. Über Ecosoft 
geht's. Oder man kennt das "richtige" Telegramm ...

//Niffko

[Jürgen S. (Firma: privat) (jschmied)]

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

[giovanne (Gast)]

Hi,
wegen Taktsperre müßte ich mal schauen. Ich meine aber es in der 
Eco-Soft gemacht zu haben, im Bereich der Sonderparameter ;-)

[typ (Gast)]

für 30.000 Starts hat unsere alte GB112 10 Jahre und 30.000h gebraucht
und das unoptimiert

für ein gut dimensioniertes modulierendes Gerät dürfen es nicht mehr als 
3.000 Starts pro Jahr werden, eher sogar nur 2.000 mit mehreren Stunden 
Laufzeit pro Start
alles andere läuft grottig schlecht (Hydraulik, Temperaturen)

[Giovanne G. (giovanne)]

Wie vermutet, in den Sonderparametern -> Antipendelzeit

[Karl M. W. (charlie-w)]

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.

[Rudi (Gast)]

Wie ist denn die default Einstellung? Die sollte doch schon auf dem Bus 
zu sehen sein ...

[Jürgen S. (Firma: privat) (jschmied)]

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

[Giovanne G. (giovanne)]

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 :-(

[Jürgen S. (Firma: privat) (jschmied)]

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

[Giovanne G. (giovanne)]

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 (Gast)]

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

Hallo Giovanne,

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.

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.

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...

Gruß
Ingo

[Giovanne G. (giovanne)]

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 (Gast)]

Giovanne Giovanne schrieb:
> Mal schauen, zumindest scheint es nicht viele zu geben die die Original
> HW/SW haben und dort mithorchen wollen.

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.

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 .


Also zum Mittloggen um die Funktion zu erkennen ist bestimmt H-Term 
besser...


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.

Aber ich habe ja sowieso keine Langeweile, eher im Gegenteil...

Gruß
Ingo

[Giovanne G. (giovanne)]

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... ;-)

[Karl M. W. (charlie-w)]

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.

[F. F. (pic18f)]

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

[IngoF (Gast)]

Hallo Franz,

ich hatte damals die Bits nummeriert. Bit 1 entspricht dem Bit0 (2^0).

Die 0 hiess mal dass die kein bestimmtes Bit gemeint ist.


Gruß
Ingo

[F. F. (pic18f)]

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

[IngoF (Gast)]

F. F. schrieb:
> Hier könnte man auch Hi und Lo dazu schreiben.

Wie meinst Du das?

Wenn z.B. Ein Wert aus zwei Bytes besteht also zwei Zeilen für den Wert?
Keine Ahnung ob das übersichtlicher ist.

Habe jetzt einfach mal oben eine kleine Erklärung der Tabellen eingefügt 
und Die Bitzählweise auf 0-basiert umgestellt. Das erste Bit ist jetzt 
als Bit0.

Gruß
Ingo

[F. F. (pic18f)]

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

[Jürgen S. (Firma: privat) (jschmied)]

> 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

[F. F. (pic18f)]

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

[Jürgen S. (Firma: privat) (jschmied)]

> 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

[Niffko (Gast)]

Jürgen Schmied schrieb:
> Der Brenner hat eine Minimalleistung ...
> Die kannst Du nicht unterschreiten.

Stimmt. Einige, meist sicherheitsrelevante, Parameter sind "hard-coded". 
Die Brennerautomaten (UBA) sind universell. Für jede Geräteart und 
Leistungsgröße gibt es ein sogenanntes Kessel-Identifikations-Modul (aka 
KIM). In diesem KIM steckt ein EEPROM, auf dem diese Parameter 
gespeichert sind.

//Niffko

[F. F. (pic18f)]

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

[F. F. (pic18f)]

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.

[Giovanne G. (giovanne)]

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.

[F. F. (pic18f)]

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

[Giovanne G. (giovanne)]

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

[F. F. (pic18f)]

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

[Giovanne G. (giovanne)]

ja
Zündung Bit3 = 0
Zubringer Bit5 = 1

0x25 => 00100101

[F. F. (pic18f)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[F. F. (pic18f)]

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?).

[Giovanne G. (giovanne)]

Zur Info, bei mir ist es auch RC30.

[F. F. (pic18f)]

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

[Jürgen S. (Firma: privat) (jschmied)]

> 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

[Danny B. (maniac103)]

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 ;)

[Jürgen S. (Firma: privat) (jschmied)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[IngoF (Gast)]

Jürgen Schmied schrieb:
> Logamatic EMS RS232 Gateway hatte anfangs mal den EMS Bus direkt
> unterstützt,

Geht das nicht mehr?

Als ich damals ein EMS-Gateway kaufen wollte hieß es dass der 
EMS-Gateway demnächst auch den EMS-Bus unterstützen würde... Das ist 
aber bestimmt schon fast 10 Jahre her..

Gruß
Ingo

[Jürgen S. (Firma: privat) (jschmied)]

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

[Giovanne G. (giovanne)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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" ...

[Giovanne G. (giovanne)]

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 ...

[F. F. (pic18f)]

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

[F. F. (pic18f)]

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

[Jürgen S. (Firma: privat) (jschmied)]

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

[F. F. (pic18f)]

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

[Moustic (Gast)]

I don't speak German, sorry !

This is easy

Kevin Heidrich schrieb:
> Alex Amend schrieb:
>> 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.
>
> ich habe mir mal dein Log angeschaut, und so wie es scheint geht die
> Kommunikation über HTTP/80 per Binary JSON.
>
> -----
>
> HTTP/1.0 200 The request has succeeded
> Content-Type: application/json
>
> veSJNc+lFfrdObDjj04tWC+pGbZELyzUiQaSZli48U+ax2nFuLmVP6m9X7M/PtRmDZc/PngS
> 6VF+9Pj8OG1XIj+7oCNQV9vAp0fGL9gboUhh8XdfqOcQbkH6eu1RzHJ1H/6mdPjM2ielVRed
> TgYvvfhOeldH64YiUN8bfnu3cjPxSn1zR5y82nSQszQ2kK7/oRaBNHJaJ1xkVXpl1y8KQrT8
> IfzTrW356VeTa+inpSehjHXp6aiiD21SDCQPBHexaNq+MMb3ZjCppyNTUhKxspybIEuNRNYP
> NEF7R/SF6rAewrwo1cLzsSB22pKqrXjxPSIbEWDCGTJDKY8suxLT5u+Dv74hIHsg0xc3fo1q
> PhEf4x5XbfveedsRqPMi+ePSQr1pEkkKyYkEkksXKEHoYk4TFKaWQSdi7yilgfc/0LJKW5cp
> jlnqppMN5ZIvKFZyL4Cc+Tl8CBVHbj2oBxPw/V2GnLFpvBoKAC9DZiNiBCLnSp+bI99TozqR
> oalkC9H/SakHzT3hN3vMpLhj/qCOiQs6+CA968AYE0qwO80pLRPi+JTsCM0oB+ecPePkiUQq
> v4m5wtVuPAUXM6Px109+VPhOeldH64YiUN8bfnu3cjOS665LPoIv0JnQrdQcebJMoRaBNHJa
> J1xkVXpl1y8KQrT8IfzTrW356VeTa+inpScIiqy5T3fgAcy3RxT42S0r
>
> ----
>
> Das ganze ist dann noch Base64 kodiert. Das Endergebnis ist dann
> allerdings wiederum ernüchternd. Nichts was man so lesen könnte. Ich
> dachte es wäre evtl. am Ende dann doch wieder JSON, aber da komme ich
> nicht weiter.
>
> Gruß
> Kevin

To decrypt this :

1. Base64 decode
2. generate MD5 for gateway password
3. generate MD5 for user password
4. concat MD5 from gtw and MD5 of userpasw
5. use this as Key for AES decryption (AES/ECB/NoPadding)

then it should become JSON human readable.

[Niffko _. (niffko)]

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

[IngoF (Gast)]

Hallo Niffko

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.

Nur Abfragen an die 0x09 dauerten länger..

Gruß
Ingo

[F. F. (pic18f)]

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.

[Danny B. (maniac103)]

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.

[Niffko _. (niffko)]

>[...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

[Danny B. (maniac103)]

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.

[Niffko _. (niffko)]

Danny Baumann schrieb:
> ... einfach weiterlaufen.

mach ich genau so ... auch keine Probleme.


//Niffko

[IngoF (Gast)]

Danny Baumann schrieb:
> Nach meiner Beobachtung macht die RC30 genau das gleiche, scheint also
> normal zu sein.

Was macht denn die RC30? Fragt sie die Telegramme dann aktiv selber noch 
mal ab.

Beim Party-Telegramm das ja aus vier oder fünf Teilen besteht gibt es 
etwas ähnliches. Ab und zu fehlt dann das letzte Telegramm (aus 
Zeitgründen?). Dort wird dann aber das Telegramm kurz später nochmal 
automatisch komplett nachgeschickt.

Aber das wird dann wohl nur die RC30/35 machen.

Gruß
Ingo

[Dirk (Gast)]

Hi

> To decrypt this :

> 1. Base64 decode
> 2. generate MD5 for gateway password
> 3. generate MD5 for user password
> 4. concat MD5 from gtw and MD5 of userpasw
> 5. use this as Key for AES decryption (AES/ECB/NoPadding)

> then it should become JSON human readable.

does not work for me.
Gateway pass ist printed on the Label
User Pass ist Pass fpr the ios App ??

AES 256?

can you please give an example
tried it with openssl and mcrypt (php) - NO Success

[Andreas H. (skyslasher)]

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ß :)

// IP Adresse oder DNS-Hostname des KM200
define( "km200_gateway_host", '192.168.1.7', true );
// Gerätepasswort. Achtung: Ohne Bindestriche und in ASCII!
define( "km200_gateway_password", 'abcdABCDabcdABCD', true );
// Eigenes Passwort wie in der App vergeben
define( "km200_private_password", 'geheim', true );
// Dreh- und Angelpunkt: Der geheime Salt der MD5-Hashes zur AES-Schlüsselerzeugung
$MD5Salt = pack(
    "c*",
    0x86, 0x78, 0x45, 0xe9, 0x7c, 0x4e, 0x29, 0xdc,
    0xe5, 0x22, 0xb9, 0xa7, 0xd3, 0xa3, 0xe0, 0x7b,
    0x15, 0x2b, 0xff, 0xad, 0xdd, 0xbe, 0xd7, 0xf5,
    0xff, 0xd8, 0x42, 0xe9, 0x89, 0x5a, 0xd1, 0xe4
);
define( "km200_crypt_md5_salt", $MD5Salt, true );
// Erste Hälfte des Schlüssels: MD5 von ( Gerätepasswort + Salt )
$key_1 = md5( km200_gateway_password . km200_crypt_md5_salt, true );
// Zweite Hälfte des Schlüssels: MD5 von ( Salt + privates Passwort )
$key_2 = md5( km200_crypt_md5_salt . km200_private_password, true );
define( "km200_crypt_key", $key_1 . $key_2, true );

function km200_Decrypt( $decryptData )
{
  $decrypt = mcrypt_decrypt(
    MCRYPT_RIJNDAEL_128,
    km200_crypt_key,
    base64_decode( $decryptData ),
    MCRYPT_MODE_ECB,
    ''
  );
  // Entferne zero padding
  $decrypt = rtrim( $decrypt, "\x00" );
  // Entferne PKCS#7 padding
  $decrypt_len = strlen( $decrypt );
  $decrypt_padchar = ord( $decrypt[ $decrypt_len - 1 ] );
  for ( $i = 0; $i < $decrypt_padchar; $i++ )
  {
    if ( $decrypt_padchar != ord( $decrypt[$decrypt_len - $i - 1] ) )
      break;
  }
  if ( $i != $decrypt_padchar )
    return $decrypt;
  else
    return substr( $decrypt, 0, $decrypt_len - $decrypt_padchar );
}

function km200_GetData( $REST_URL )
{
  $options = array(
    'http' => array(
      'method' => "GET",
      'header' => "Accept: application/json\r\n" .
                  "User-Agent: TeleHeater/2.2.3\r\n"
    )
  );
  $context = stream_context_create( $options );
  return json_decode(
    km200_Decrypt(
      file_get_contents(
        'http://' . km200_gateway_host . $REST_URL,
        false,
        $context
      )
    )
  );
}

// Beispielaufruf
$REST_Service = '/system';
$json = km200_GetData( $REST_Service );
echo "Service: " . $REST_Service . "\n";
var_dump( $json );

[Stefan M. (stefan-muehlbauer)]

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

[Andreas H. (skyslasher)]

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

[Baumeister (Gast)]

Hallo,

na endlich hat sich einerf die Mühe gemacht und eine Lösung zur 
Dekodierung des json strings gefunden. Ich hatte vor ca. einem Jahr auch 
versucht hier etwas zu finden, war aber an der dekodierung gescheitert.

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?

[Andreas H. (skyslasher)]

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

[Baumeister (Gast)]

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

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.

Eventuell eine Änderung in der Firmware?

[Andreas H. (skyslasher)]

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

[Baumeister (Gast)]

Hallo,

es liegt nicht an dem Script. Das andere will auch nicht. Irgendwie 
antwortet mein Gateway auf Abfragen die nicht von "Buderus" kommen immer 
mit dieser Fehlernachricht.

Da muss noch etwas sein. Ja die zusätzlichen header hatte ich auch schon 
definiert. Das war es aber nicht.

Übrigens, das script von der anderen Seite kann jetzt auch Werte setzen 
und nicht nur lesen.

Irgendwie muss es gehen, denn meine Firmware und Hardware scheint bei 
anderen zu gehen.

[Baumeister (Gast)]

Gelöst:

Ich nehme alles zurück und behaupte nun das Gegenteil. Es läuft. Bei mir 
ist der Header irgendwie anders. Habe noch mal gesnifft und 1zu1 den 
Headerv der App eingetragen

Danke

[Lars R. (lars_r48)]

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

[Lars R. (lars_r48)]

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

Was musstest du ändern damit es bei dir lief?

[Lars R. (lars_r48)]

Mann benötigt schon die module dazu...


sudo php5enmod mcrypt
sudo service apache2 restart

[Marius (Gast)]

Hallo,

gibt es eine möglichkeit den Netio über Levelshifter direkt mit dem 
Raspi zu verbinden um das LAN interface einzusparen?

Hier:

Beitrag "Re: EMS > Adapter > NetIO > Raspi"

wird das auch gefragt aber bis jetzt keine Antwort. Ich will mir eine 
kleine Schaltung mit dem Mega644 bauen damit ich nicht den ganzen Netio 
dafür verwenden muss (ich hab nur einen und der ist für was anderes)
Die Sache soll dann an meiner Heizung permanent dran bleiben damit ich 
etwas loggen kann...

Marius.

[Juergen O. (juergen_o)]

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.

[Stefan S. (hf_fuzzi)]

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

[nobody0472 (Gast)]

Hi all,

am 13.07. hat Baumeister folgendes geschrieben:

> Gelöst:

>Ich nehme alles zurück und behaupte nun das Gegenteil. Es läuft. Bei mir
> ist der Header irgendwie anders. Habe noch mal gesnifft und 1zu1 den
> Headerv der App eingetragen

Ich stehe nun vor dem gleichen Problem (habe ein KM50) und bekomme exakt 
die gleiche Antwort.
Ist hier bekannt, wie Baumeister das gelöst hat, und was im Header nun 
stehen muß?

Vielen Dank

[Fa K. (prof72)]

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

[IngoF (Gast)]

Fa Ke schrieb:
> Um nichts doppelt zu machen: hat schon jemand Fortschritte mit diesen
> Telegrammen gedacht?

Hallo FaKe

hast Du Lust und Zeit das in das EMS-Wiki einzupflegen?
Oder kannst Du Deine Erkenntnisse zur weitergeben damit ich sie ins Wiki 
einbauen kann?

Wenn man zusammen an einer Baustelle arbeitet wird es meistens 
einfacher.

Habe leider "nur" EMS ohne "+" kann da selber nichts herausfinden.
Wer hat denn alles dieses "+"?

Gruß
IngoF

[IngoF (Gast)]

Habe schon mal Platz für die Infos geschaffen.
Ein Teil der EMS Seiten habe ich schon mal hein kopiert.

Falls es Gemeinsamkeiten von EMS und EMS+ gibt kommen die dann etwas 
höher in den gemeinsamen Teil.

Wer Infos hat gerne hier posten...

Falls jemand selber einpflegen will ist auch ganz schnell ein Benutzer 
im Wiki eingerichtet.
Die Automatisierte Anmeldung musste ich wegen SPAM leider "abschalten".

Gruß
IngoF

[Fa K. (prof72)]

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:

IO: Got bytes 0xaa 0x55 0x11 0x8 00 0x7 00 0xb 0x1 00 00 00 00 00 00 0x1 00 00 00 00 0x4 
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:

IOBytes[22.10.2014 15:52:54]: 0xaa  0x55  0x08  0x10  0x00  0xff  0x00  0x01  0x67  0x00  0x00  0x89 
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

[Andy (Gast)]

Juergen O. schrieb:
> Hi Marius,
> ich versuche was ähnliches mit einem ESP8266 Modul.

Ich bin zwar nicht Marius, bin aber trotzdemsehr interessiert an deinem 
Projekt. Ist es mittels Ethersex überhaupt möglich die Daten ohne 
Netzwerk an den Raspi zu übertragen? Die Software auf dem Raspi muss ja 
dann auch angepasst werden (der Collectord wenn ich mich richtig 
erinnere). Die Hardware ist nicht so das Problem nur mit der Software 
steige ich da nicht so ganz durch... Ich würde mir halt gerne die 
Netzwerkgeschichte Sparen da der Raspi direkt neben dem EMS-Platinchen 
montiert wird (in einer großen Aufputzkiste)...

Grüße
Andy

[Andy (Gast)]

Nachtrag:
Ich habe mich etwas eingelesen und meine nun das es behandlungstechnisch 
auf der Raspi-Seite egal ist ob die Daten über Kablegebundenes Netzwerk 
oder über Wlan kommen.
Ist das Korrekt?

[Niffko _. (niffko)]

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 (Gast)]

Hallo,

warum sind bei der EMS Schaltung die Widerstände R5/R6 am Ausgang des 
oberen Komparators? Da der ATmega ja mit 5V Pegel Arbeitet könnte R5 ja 
wegfallen oder? Der Pull-Up ist ja notwendig da der LM393 einen Open 
Collector Ausgang hat. Aber der Widerstand R5 in der Leitung zum NetIO 
macht für mich irgendwie keinen Sinn. Hab ich da was übersehen?

Grüße
Andy

[Fa K. (prof72)]

@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

[Jürgen S. (Firma: privat) (jschmied)]

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

[Fa K. (prof72)]

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

[Fa K. (prof72)]

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

[Niffko _. (niffko)]

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

[Fa K. (prof72)]

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

[IngoF (Gast)]

Hallo,

mir ist gerade mal aufgefallen dass 0xff z.B. immer bei Quelle 0x10 Ziel 
0x00 aufgetaucht ist.
Sobald aber 0x48 in Quelle oder Ziel auftaucht kommt immer 0xf7 oder 
0xf6
Dabei unterscheidet sich ja nur das Bit0.

Wer ist den 0x48?

Vielleicht bringt es was wenn man nur die Telegramme mit >=0xf0 
herausfiltert und nach Absender oder Ziel sortiert.

Vielleicht gibt es ja einen Zusammenhang mit den neuen Telgrammtypen 
(0x01a5)

Gruß
IngoF

[Fa K. (prof72)]

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

[Torsten G. (tuskegee)]

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

[Maarten H (Gast)]

Hello all,

Sorry but my German writing is not good enough, but ready no problem.

I'm already for a year or so ready all your interesting studies and hope 
to "control" my Buderus also. My setup here is:
RC35
BC 10 controller
GB125 with BE2.3 (Heater on oil)
LT135 (Boiler)

I build the EMS-NetIO-adaptor and use the Pollin NET-IO with the 
Ethersex code.
I have also compiled the ems collector on a Linux system.

I can communicate via the browser with the EMCD
On the UART RX port of the AVR is data comming in.

But with the emcd?ems stats I get nothing.

Can some please help in getting this running ???

See also the ems_stats and ems_UART_dump


Many thanks Maarten von Belgiem

[IngoF (Gast)]

Looks like your ems-board is out of order or the serialSpeed is wrong.
You are receiving wrong data.
9600 8N1 should be OK for the EMS-Bus.

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

Is this the circuit, you have built:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#hardware

[IngoF (Gast)]

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

[Danny B. (maniac103)]

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 (Gast)]

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.

[IngoF (Gast)]

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..

[Danny B. (maniac103)]

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.

[Maarten H (Gast)]

IngoF schrieb:
> Looks like your ems-board is out of order or the serialSpeed is wrong.
> You are receiving wrong data.
> 9600 8N1 should be OK for the EMS-Bus.
>
> I suppose the Counters are still at zero because the are no
> "framing-bytes" (aa 55).
>
> Is this the circuit, you have built:
> http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#hardware

Dear Ingo,

Thanks a lot for your reaction, and the great work you guys make here.

Yes indeed I used this circuit, connected to the "EMS" from my BC10 and 
when I measure with my scope I see the expected signals and levels, all 
looks clean. I see no framing start (aa 55) however I see a lot of "3F" 
connecting Putty via an MAX.
I indeed can also to the conclusion it is NOT the Net-IO with the 
Ehtersex, but now already for months (with pause) I'm stuck here.

Any other idea how to debug ?

Best regards Maarten

[Danny B. (maniac103)]

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)

[Karl M. W. (charlie-w)]

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 (Gast)]

Maarten H schrieb:
> connecting Putty via an MAX.

maybe thats the problem.

an USB-Serial-Cable wit a max232 has RS232-level. The board ist designed 
for the serial-port  with TTL-level. You must use an 
USB-TTL-Serial-Cable to check if the ems-board works fine.

if you do not have a TTL-Cable you can swap the both inputpins 2&3 of 
IC1A.
But do not forget to swap back if you want to use it with your AVR.

Or you can put an CMOS Inverter between the output of the ems-board and 
the RX of the serial-cable.

Or is the serial-port connector at the AVR-port a RS232-version, too?

[Maarten H (Gast)]

IngoF schrieb:
> Maarten H schrieb:
>> connecting Putty via an MAX.
>
> maybe thats the problem.
>
> an USB-Serial-Cable wit a max232 has RS232-level. The board ist designed
> for the serial-port  with TTL-level. You must use an
> USB-TTL-Serial-Cable to check if the ems-board works fine.
>
> if you do not have a TTL-Cable you can swap the both inputpins 2&3 of
> IC1A.
> But do not forget to swap back if you want to use it with your AVR.
>
> Or you can put an CMOS Inverter between the output of the ems-board and
> the RX of the serial-cable.
>
> Or is the serial-port connector at the AVR-port a RS232-version, too?

Hi Ingo,

I have an invertor added behind the EMS-NetIO-adaptor, than I have a MAX 
to convert to RS232 levels and than a RS232-USB dongle to convert to 
USB, with which I enter my PC. I use this invertor as the MAX also 
inverts the signals.
It is a pitty that I have only an old analog oscilloscope here at home, 
else I could provide some signals.

Best regards Maarten

[IngoF (Gast)]

Maarten H schrieb:
> I have an invertor added behind the EMS-NetIO-adaptor, than I have a MAX
to convert to RS232

I suppose thats the problem.
if the board has a ttl-Output you only need a max232 and a usb-Rs232 
cable.
the max232 has a inverter inside.

or you can use an inverter instead the max232 for tests.

Then you should see the right data at the terminal program.

But that is not the reason for the AVR-Problem...

[Torsten G. (tuskegee)]

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

[Fa K. (prof72)]

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

[Maarten H (Gast)]

IngoF schrieb:
> Maarten H schrieb:
>> I have an invertor added behind the EMS-NetIO-adaptor, than I have a MAX
> to convert to RS232
>
> I suppose thats the problem.
> if the board has a ttl-Output you only need a max232 and a usb-Rs232
> cable.
> the max232 has a inverter inside.
>
> or you can use an inverter instead the max232 for tests.
>
> Then you should see the right data at the terminal program.
>
> But that is not the reason for the AVR-Problem...


Hello Ingo,

I did some more work and have some answers.
You are right with the "inverter discussion" , UART-TTL and RS232 have 
inverted polarity. The bad news however is that I tried both already.

What I found was that the data slicer was not always working correctly, 
I found that adapting some values (C4 1nF --> 330pF, R7 100K --> 82K) 
gave more stable data. I compared the dat with the data slicer of the 
KM200, and the result was very simulair

Thr bad news however is that the AVR with EMS_Ethersex still is not 
reacting at all.

When I monitor the UARt signal with Hyperserialport 8n1, I see all 
messages starting with 3F 00, not with the AA 55 you mention ? I attach 
a txt file with a short capture. I monitor the bus called "EMS" on the 
BC10, the same bus where you normally connect the KM200. Can it be the 
case that this bus has as adress 3F ?

Thanks a lot for your time,


Maarten

[Frank S. (blaueslicht)]

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:

 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
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
MESSAGE[14.12.2014 18:57:36]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64
MESSAGE[14.12.2014 18:57:51]: source 0x18, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x00 0xf3 0x02 0x91
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
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
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
MESSAGE[14.12.2014 18:58:35]: source 0x18, dest 0x08, type 0x1a, offset 0, data: 0x2a 0x64 0x64
MESSAGE[14.12.2014 18:58:50]: source 0x18, dest 0x00, type 0xff, offset 13, data: 0x01 0xa5 0x00 0xf2 0x02 0x92
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
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
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
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?

[Niffko _. (niffko)]

@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

[Karl M. W. (charlie-w)]

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.

[Karl M. W. (charlie-w)]

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.

[Danny B. (maniac103)]

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?)

[Karl M. W. (charlie-w)]

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.

[Danny B. (maniac103)]

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 :)

[Karl M. W. (charlie-w)]

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.

[Frank S. (blaueslicht)]

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

[Karl M. W. (charlie-w)]

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.

[Niffko _. (niffko)]

@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

[Ingo F. (ingof)]

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...

[Niffko _. (niffko)]

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

[Frank S. (blaueslicht)]

So, offensichtlich funkt der RC200 doch die Werte ungefragt auf den Bus. 
War wohl bisher zu blind :)
Folgende Werte habe ich identifiziert:

IO: Got bytes 0xaa 0x55 0x1f 0x18 00 0xff 00 0x1 0xa5 00 0xe0 0x21 0x2b 
0x29 00 0x2b 0x20 00 0x2a 0x3 0x3 0x1 00 0x2a 0x3 0xd2 00 00 0x11 0x1 
0x3 0x8 0xbe 00 0xfe

0x18 (Wert 4) = RC200
0xe0 (Wert 11) = aktuelle Raumtemp 22,4Grad
0x21 (Wert 12) = Raum Nacht Soll 16,5 Grad
0x2b (Wert 13) = Raum Soll aktuell (21,5 Grad)
0x29 (Wert 14) = Kessel Soll
0x00 (Wert 18) = Tag (0x01 für Nacht)

Die Werte "0x2a" (Wert 19 und 24) ist wohl ein Zähler, der pro Nachricht 
um 1 dekrementiert
Der Wert "0xd2" (Wert 26) inkrementiert um 1 pro Nachricht

Bei jeder Raumtemp Änderung schickt RC200 zusätzlich ein "Update":
IO: Got bytes 0xaa 0x55 0x8 0x18 00 0xff 00 0x1 0xa5 00 0xde 0x9d

0xde = aktuelle Raumtemp 22,2Grad

Jetzt die Preisfrage: Wie bekomme ich diese Erkenntnisse in collectord ?
Das Spannende ist wohl, dass es mehrere Typ "ff" Nachrichten gibt (siehe 
mein voheriger Post).

[Danny B. (maniac103)]

Niffko _ schrieb:
> 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.

Ich hab mal einen 'emsplus'-Branch gepusht, der dieses Format 
unterstützt, d.h. bei dem 'raw read 0x18 0x139 0 255' genau diesen 
Output liefert. Ordentlich testen kann ich das mangels EMS plus leider 
nicht.

Frank S. schrieb:
> Jetzt die Preisfrage: Wie bekomme ich diese Erkenntnisse in collectord ?
> Das Spannende ist wohl, dass es mehrere Typ "ff" Nachrichten gibt (siehe
> mein voheriger Post).

Das ist eine sehr spannende Frage. Ich bin mir nicht sicher, ob ich das 
blind coden will (da ich - siehe oben - keinen EMS plus habe) (genauer 
gesagt bin ich mir ziemlich sicher, dass ich das nicht blind hincoden 
möchte); also wäre es mir sehr lieb, wenn es so wie bei Moosy's 
Änderungen liefe: jemand macht einen Pull Request (oder schickt mir 
meinentwegen den geänderten Code per Mail), und ich ziehe dann höchstens 
noch ein paar Architekturelle Dinge glatt. Die Parser-Infrastruktur 
sollte im oben erwähnten emsplus-Branch soweit sein, dass man die neuen 
Nachrichten verhältnismäßig einfach in das zentrale switch-Statement 
einbauen kann; der Ausbau des CommandHandlers ist dann natürlich etwas 
mehr Aufwand.

Also, Freiwillige vor :)

[Niffko (Gast)]

Frank S. schrieb:
> IO: Got bytes 0xaa 0x55 0x1f 0x18 00 0xff 00 0x1 0xa5 00 0xe0 0x21 0x2b
> 0x29 00 0x2b 0x20 00 0x2a 0x3 0x3 0x1 00 0x2a 0x3 0xd2 00 00 0x11 0x1
> 0x3 0x8 0xbe 00 0xfe
>
> 0x18 (Wert 4) = RC200
> 0xe0 (Wert 11) = aktuelle Raumtemp 22,4Grad
> 0x21 (Wert 12) = Raum Nacht Soll 16,5 Grad
> 0x2b (Wert 13) = Raum Soll aktuell (21,5 Grad)
> 0x29 (Wert 14) = Kessel Soll
> 0x00 (Wert 18) = Tag (0x01 für Nacht)

OK. Da ich meinen Brenner selbst steuere, habe ich im RC300 keinen 
Heizkreis aktiviert. Dashalb kommt das 1A5 Telegramm bei mir ohne Inhalt 
auf den Bus.

Ich habe testweise einen Heizkreis aktiviert und konnte deine 
Feststellung nachvollziehen.

Du müsstest die "00"(Wert10) noch mit dazu parsen. Raumtemperatur ist 
16Bit, sonst wär bei 25,5°C Sense.

//Niffko

[Ingo F. (ingof)]

Niffko _ schrieb:
> Was mich bei den Telegrammen irgendwie stört, ist das "FF" zwischen
> Offset und Subtype.

Kann es sein dass der alte Offset-Wert keine Funktion mehr hat und nur 
von Modulen gesendet wird die EMS und EMS-Plus verstehen?

Oder hat der Offset 0xff noch eine andere Bedeutung?

Dann könnte der neue Offset-Wert hinter dem 16-Bit-Typ kommen.
nur das Erste und zweite Byte funktioniert nicht als Offset
Beide Bytes könnte schon eher in Frage kommen.

Vielleicht wurde ja auch die Telegramm/Speicherlänge verändert und es 
ist ein 16-Bit-Offset

Oder ist das jetzt ein 16-Bit Offset oder noch ein weiterer neuer 
Datentyp?

Kann auch sein dass es nur ein Messwert ist oder eine Art Zeitstempel?

Gruß
Ingo

[Niffko _. (niffko)]

Hallo Ingo,

wenn ich 0x1B9 abfrage, sieht das so aus.

//Niffko

[Wolfgang (Gast)]

Bin nun auch stolzer Anwender einer Heizung mit BC10 und RC300. Bevor 
ich mir nun eine Platine ätze, frage ich mal in die Runde, ob jemand 
Platinen über hat.

Wenn ja, bitte ich um Info.

Zusätzlich will ich mir zu Testzwecken eine EMS Anbindung mit einem 
Atmel Mega 8 bauen. Nur so als serielle Anbindung für PC/Terminal.

[Ingo F. (ingof)]

War die Heizung ein Weihnachtsgeschenk ;-)

[Juergen O. (juergen_o)]

Wolfgang schrieb:
> Bin nun auch stolzer Anwender einer Heizung mit BC10 und RC300. Bevor
> ich mir nun eine Platine ätze, frage ich mal in die Runde, ob jemand
> Platinen über hat.

Habe hier noch vier Platinchen abzugeben. Design Niffko / NetIO mit 
zusätzlichen Jumperfeldern, Aduino-kompatibler Steckerleiste sowie
Sockel für ein ESP8266-ESP01 Modul.

Selbstkostenpreis: 3€ incl. Porto.

[Maarten H (Gast)]

Juergen O. schrieb:
> Wolfgang schrieb:
>> Bin nun auch stolzer Anwender einer Heizung mit BC10 und RC300. Bevor
>> ich mir nun eine Platine ätze, frage ich mal in die Runde, ob jemand
>> Platinen über hat.
>
> Habe hier noch vier Platinchen abzugeben. Design Niffko / NetIO mit
> zusätzlichen Jumperfeldern, Aduino-kompatibler Steckerleiste sowie
> Sockel für ein ESP8266-ESP01 Modul.
>
> Selbstkostenpreis: 3€ incl. Porto.


Dear Jurgen,

I'm very interested to buy such a platinchen.
When you contact me by mail: [e-mail]
and give me your bank account I will transfer the Selbstkostenpreis: 3€ 
incl. Porto.


Many thanks Maarten

[Juergen O. (juergen_o)]

Sorry Maarten,
just delivered the last one.

If there's sufficient interest, I'll develop a new one, this
time for ESP8266-12, also a bit more multi purpose.

[Karl M. W. (charlie-w)]

Sers Jürgen,

Juergen O. schrieb:
> If there's sufficient interest

... dann kannst'e mich mal auf die Liste setzen.

Klingt interessant, dieser ESP8266-x.

Noch ein paar Fragen, wenns beliebt:

Im Moment betreibst Du die Platine als EMS-Adapter für den NetIO, 
richtig?
Hast Du für den ESP8266 schon eine Firmware gebaut, oder ist der Sockel 
nur fakultativ?
Wie hast Du die Stromversorgung (3.3V) realisiert?

Gruß und Dank
Karl M.

[Juergen O. (juergen_o)]

Ich habe keinen NetIO dran, sondern das ESP8266-01 Modul.
Bastle grade an der Firmware herum - letztendlich wird die stark an 
EtherSex angenähert sein.
Die 3.3V erzeuge ich momentan noch mit einem eigenen Netzteil mit einem 
StepDown Wandler. Ziel ist jedoch, direkt über den EMS-Bus zu versorgen.