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.

[Ingo F. (ingof)]

Juergen O. schrieb:
> Ziel ist jedoch, direkt über den EMS-Bus zu versorgen.

Die Stromversorgung dürfte nicht das Problem sein... habe ich auch so 
gemacht. Allerdings ist dann nur wichtig das der Stromverbruach nicht zu 
stark schwankt. Das könnte dann als Sendeversuch verstanden werden und 
den Bus wuschig machen

Kenne den ESP8266-01 nicht. Könnte mir aber vorstellen dass der 
WLAN-Chip auch mal gerne schlagartig den Stromverbruach beim senden 
ändern könnte.
Oder liege ich da komplett falsch?

[Juergen O. (juergen_o)]

Nein, liegste vollkommen richtig.
Das ESP zieht ca. 17mA,  im Burst (beim Senden) jedoch bis zu 250mA.

Deshalb wollte ich einen Buck-Konverter (mit Vorwiderstand zu Uems) 
einsetzen, um den Eingangsstrom zu reduzieren.

Funktioniert jedoch nicht sauber.
0R: Der Eingangs-Elko des SDC filtert sauber alle Signale raus ;)
39R: Protokoll verstümmelt - der Komparator kommt aus dem Tritt
47R: kurze Telegramme kommen durch (wie bspw. 90 00 10 00 und
89 00 09 00), längere werden jedoch verstümmelt.
68R und größer: desaströs - der SDC schwingt nicht mehr an, R hängt voll 
als ohmsche Last an Uems...

In allen Fällen geht die Heizung binnen kurzem auf Störung - zeigt nur
noch ein blinkendes "-" an.

Also fällt die Eigenversorgung mit dem ESP (zumindest via Uems) flach.

[Erik B. (erik_bies)]

@Juergen O

i'M also interested when you succeeded with a new PCB based on 
ESP8266-12.
My ESP8266-12 is underway. If you are making new ones, count me in for 
one.

Hope indeed to have it powered by the bus

[Juergen O. (juergen_o)]

The problem will be the powersupply.
My EMS has approx. 15V w/o load. So a linear regulator for 3.3V isn't a 
choice at all, 'cause the ESP-12 requires approx 75mA w/o sending.

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

> w/o
w/o ist mir nicht geläufig, was darf ich darunter verstehen?

Im Datenblatt lese ich:

Transmit 802.11b, CCK 1Mbps,   POUT=+19.5dBm   215 mA
Transmit 802.11b, CCK 11Mbps,  POUT=+18.5dBm   197 mA
Transmit 802.11g, OFDM 54Mbps, POUT=+16dBm     145 mA
Transmit 802.11n, MCS7,        POUT=+14dBm     135 mA

Das ist einiges! Wieviel "sporadische" Belastung verträgt denn der Bus, 
ohne das als Sendesequenz zu interpretieren?

Könnte sowas funktionieren:
EMS - Vorwiderstand - Längsregler - Goldcap - VCC?
Oder gleich:
EMS - Vorwiderstand - Längsregler - CR2032 - VCC?

[Ingo F. (ingof)]

Charlie W. schrieb:
> Wieviel "sporadische" Belastung verträgt denn der Bus

Also auf dem EMS-Bus wird in gesendet indem der Bus mit 227,5 Ohm 
belastet wird.
Bei etwa 15Volt sind das etwa 66mA.

Habe jetzt keine Ahnung wo die Ansprechscwelle liegt. sonst einfach mal 
ausprobieren wieviel Ohm den Bus durcheinander bringen wenn den 
Widerstand parallel zum Bus kurz anklemmt wird

Vermute mal dass es bei etwa 20-30mA sein werden.

Meine RC30 wird bestimmt nicht mit 30mA auskommen. Also muss dass 
irgendwie klappen können.
Hat jemand mal den Stromverbrauch von der RC30,35,300 oder 350 gemessen?

Ein einfacher Wiederstand in Reihe wird dann wohl nicht helfen.

Aber vielleicht reicht es ja auch dem einen wenn die Schaltung an der 
Diagnosebuchse angeklemmt wird (3,5mm Klinke). Dort sind 12 Volt drauf.
Wie stark die 12V-belastet werden dürfen ist mir unbekannt.

[Ingo F. (ingof)]

Charlie W. schrieb:
>> w/o load
> w/o ist mir nicht geläufig,

w/o wird without heissen. Also 15 Volt ohne Last

Juergen O. schrieb:
> Also fällt die Eigenversorgung mit dem ESP (zumindest via Uems) flach.

Also der Raumcontroller von Buderus scheint das ja zu schaffen. Fragt 
sich nur wieviel Aufwand das ist dafür eine Spannungsregelung mit Buffer 
zu entwickeln.

In meiner RC30 ist ein 5,5V 0,4F Goldcap eingebaut der einen 78L05 
buffert. Vermutlch wird das beim WLAN-Chip nicht ganz so einfach sein.

[Norbert S. (junky-zs)]

Hallo,

ich finde die Verwendung des ESP8266 für die Heizungs-Kommunikation 
aufregend und bin gespannt was ihr noch realisiert.
Ich selber habe keine Buderus sondern eine Junkersanlage, aber da ist 
der Heizungs-Bus mit seinen Eigenschaften sehr ähnlich.
Ein paar Hinweise wollte ich zu dem Thema loswerden weil es mich auch 
sehr interessiert:

Charlie W. schrieb:
> Könnte sowas funktionieren:
> EMS - Vorwiderstand - Längsregler - Goldcap - VCC?
Der Vorwiderstand und Längsregler setzen die ohnehin knapp bemessene 
Leistung nur in Wärme um. Es muss ein Stepdown-Wandler verwendet werden, 
mit möglichst hohem Wirkungsgrad.
Mit der Annahme, das die Strom-Schwelle bei ca.: 50mA liegt und bei 
einer Versorgungsspannung von minimal 10 Volt liefert der Bus für einen 
Client gerade mal 0,5Watt (schön gerechnet).
Das ESP-Modul im Sendebetrieb und maximaler Leistung benötigt 3.3V * 
0,215mA = 0,71 Watt.
Das wird also sehr sehr knapp und tut dem Bus nicht gut, jedoch wird die 
maximale Sendeleistung ja nicht zu 100% der Zeit benötigt.
Daher ist es schon gut zu wissen, wieviel Bytes/Zeiteinheit und wieviel 
Pause zwischen den Sendevorgängen bleibt um Luft (Strom) zu holen.
Um den Stepdown-Wandler kommt man nicht herum, leider ist die Antenne 
fest verbaut. Da könnte ich mir noch eine effektivere vorstellen um die 
benötigte Sendeenergie und Stromaufnahme zu reduzieren.

Gruß Norbert

[Ingo F. (ingof)]

Norbert S. schrieb:
> Mit der Annahme, das die Strom-Schwelle bei ca.: 50mA liegt

Wenn es möglich ist den Stromverbrauch langsam steigern, könnte es auch 
möglich sein Mehr Strom zu entnehmen. Hat jemand eine Idee wie das 
möglich sein könnte? Vielleicht die Ausgangsspannung des 
Step-Down-Wandler langsam ansteigen lassen bis zu 3,3V.

Dann müsste das ESP-Modul bei erreichen der richtigen Spannung erst 
aktiviert werden.

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

Hallo Ingo und Norbert,

Norbert S. schrieb:
> Ich selber habe keine Buderus sondern eine Junkersanlage.
... das wissen wir doch längst, oder glaubst Du im Ernst, wir würden 
Deinen coolen Thread nicht mitlesen? ;-)

> Der Vorwiderstand und Längsregler setzen die ohnehin knapp bemessene
> Leistung nur in Wärme um.
... na klar, sind doch existentielle Bestandteile einer Heizung. ;-)

> ... knapp bemessene Leistung ...
Kommt m.E. darauf an, was man betrachtet.
Der EMS-Bus kann mit "vielen" Modulen betrieben werden. Meine RC35 
glimmt nach Datenblatt mit Hintergrundbeleuchtung bei 0.6W. Unter 16V 
nach Adam Ries und Georg Ohm also 37,5mA. Andere Module werden in 
ähnlicher Größenordnung liegen. Daraus folgere ich mal, dass der Bus 
genügend Leistungsreserven hat.
Kritisch ist doch die zeitlich punktuelle Belastung, die über die als 
"Sendebelastung" verstandene Schwelle hinausgeht. Der kann man m.E. mit 
einem entsprechend dimensionierten Vorwiderstand (nach  Ingo: I < 20mA 
==> bei 16V ca. 820R) begegnen. Dahinter eben der Regler und ein Puffer. 
Vielleicht wäre eine CR2032 o.ä., im Sinne der Pufferfähigkeit, besser 
geeignet als ein Goldcap?
Oder sind meine Gedanken hier auf einer falschen Fährte?

Gruß aus der derzeit frühlingshaften Wetterau
Karl M.

ps: je suis charlie vraiment!

[Ingo F. (ingof)]

Karl M. W. schrieb:
> I < 20mA
> ==> bei 16V ca. 820R) begegnen.

Das wäre dann für das ESP-Modul dann wohl zu wenig. 20mA von der Quelle 
gibt auch nur 20mA am Ausgang bei Linewarregelung. Das würde dann 
bedeuten dass etwa die 5fache Leistung im Linearregler verbraten wird.

Das beste wäre ein Step-Down-Wandler und dann vielleicht durch Bufferung 
den Stromschwankungen unter z.B. 20mA halten z.B. 60-80mA. Der Strom war 
nur geschätzt und müsste getestet werden.

Die Pufferung duch eine Knopfzelle wird nichts bringen. Habe keinhe 
Ahnung wie lange eine Knopfzelle bei dem Stromverbrauch für die 
Pufferung halten würe. Dann könnte man vermutlich besser AA-Akkus 
nehmen, oder?

Aber hier geht es ja eher um die Schaltung komplett über den Bus 
versorgen lassen zu wollen.

[Norbert S. (junky-zs)]

Hallo,
Karl M. W. schrieb:
>Der kann man m.E. mit einem entsprechend dimensionierten Vorwiderstand ca. 820R) 
>begegnen.
Versuch macht klug, ich kann nur theoretisch rumschwätze, weil ich das 
ESP-Modul noch nicht habe.

Eventuell kann mann ja das ganze ein wenig entspannen (zeitlich) wenn 
man eben NICHT mit der laangsamen Baudrate von EMS (4800) Baud sendet 
sondern mal einwenig flotter auf der WiFi-Seite. Dafür ist dann 
allerdings auch die Software im ESP-Modul anzupassen.
Das entspannt zwar nicht die Avarage-Stromaufnahme, aber kurzer Burst 
und lange Pause zum Strom-Tanken!
Dann kannst du eventuell auch bei deinem Widerstand bleiben und statt 
eines Gold-Cap nur einen in Silber nehmen !

Gruß Norbert

[Juergen O. (juergen_o)]

Ich warte noch auf meinen Trenn-Trafo, damit ich vernünftige Messungen 
bei der Spannungsversorgung durchführen kann.
Laut Hersteller Espressif liegt die Stromaufnahme des Modules zwischen 
0.9mA im Sleep-Mode und max 170mA im Sendebetrieb 
(http://bbs.espressif.com/viewtopic.php?f=6&t=133).

Problem ist anscheinend der Buck-Konverter selbst. Sobald dieser an Uems 
(Ausgang Gleichrichter) angeschlossen wird, zieht es den EMS-Bus nieder.
Habe bereits eine Variante mit 2mA Ruhestrom probiert - ändert nichts.
Die Idee ist nun, einen einfachen Längsregler (Transistor, Z-Diode, 
Widerstand) vor den Buck-Konverter zu schalten, um diesen mit Uems-3V zu 
versorgen und den EMS-Bus etwas besser vom Konverter zu entkoppeln.

Die eigentliche Schnittstelle funktioniert bereits im Lesebetrieb. 
Wesentlich scheint hier zu sein, das der 4.7k Ausgangswiderstand am 
LM339 deutlich niederohmiger (ca 100R) ausgeführt wird.
Mit einem 4k7 gibt es seltsame Latch-Effekte  nachdem auf dem Bus der 
BRK gesendet wurde. Für eine gewisse Zeit (muß nochmal messen) geht das 
Rx-Signal nicht auf GND, sondern auf max 2V. Hierdurch kommen natürlich 
verstümmelte Zeichen auf dem Rx an.

[Juergen O. (juergen_o)]

Längsregler vorm Bulk-Converter funktioniert. Allerdings braucht es 
einen relativ fetten Kondensator am Ausgang, andernfalls wird die 
EMS-Kommunikation gestört.
Im Anhang mal die Stromaufnahme im Uems Zweig, mit 1R Shunt gemessen.

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

Juergen O. schrieb:
> ... Längsregler vorm Bulk-Converter funktioniert.

... sehr schön!

> ... fetten Kondensator ...

oder Goldcap. ;-)

Magst Du nicht einen separaten Fred eröffnen, nach Motto:
EMS <> ESP8266-12 <> WLAN

[Juergen O. (juergen_o)]

Der kommt - wollte nur nicht den halben Ansatz so stehen lassen.

[Martin B. (martin_b13)]

Hallo,

ich habe mir die Stecke EMS > Adapter > NetIO > Raspi aufgebaut. Vielen 
Dank an den ganzen fleißigen Entwicklern die hier ihr Projekt 
veröffentlicht haben und es mir so möglich war daran Teil zu haben. ;-)

Ich habe bei den Frontend von Danny wie auch von Mosi einige Fehler bei 
der Auswertung der EMS Telegramme. Mein Heizanlage ist ein Buderus 
GB135-25 Ölbrenner mit RC30 V2.02, BC10 2.0 und UBA 2.01.

Frontend Danny
Warmwasser Soll: 10°C an Stelle -> 45°C
Warmwasser Ist: -3200°C (hier wird Zeitweise der korrekte Wert 
Angezeigt!?)
Außen gedämpft: keine Anzeige
Raumtemp. IST: 3200°C

Frontend Moosi zusätzlich
Die Regelart der Anlage wird als Raumtemperatur geführt erkannt, das ist 
aber falsch, tatsächlich ist die Anlage Außentemperaturgefährt. Die 
Heizkurve im Frontend wird deshalb nicht angezeigt.

Ich habe mal mit dem Collector ein Logfile erstellt, wäre für eine 
Lösung und Unterstützung sehr Dankbar.

Grüße Martin

[Martin B. (martin_b13)]

In meinem Log habe ich folgendes Entdeckt:

Immer nach dem Telegramm

source 0x08, dest 0x00, type 0x18, offset 0

ist die WWtemperatur bei -3200°C

bei einem Telegramm

source 0x08, dest 0x00, type 0x34, offset 0

wird die WWtemperatur hingegen richtig berechnet.

Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10, 
dest 0x00, type 0x3e, offset 0

[Ingo F. (ingof)]

Martin Berger schrieb:
> Immer nach dem Telegramm
> source 0x08, dest 0x00, type 0x18, offset 0
> ist die WWtemperatur bei -3200°C
> bei einem Telegramm
> source 0x08, dest 0x00, type 0x34, offset 0
> wird die WWtemperatur hingegen richtig berechnet.

Das Telegramm 0x18 kommt von der Brennersteuerung. Diese scheint keine 
Warmwassertemperatur zu haben (0x8000 wenn nicht vorhanden = -3276,8°C)

Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das 
müsste vermutlich am besten in den EMS-Collector, oder?

Martin Berger schrieb:
> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10,
> dest 0x00, type 0x3e, offset 0

Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller.

Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D 
(temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder?

Du hast Doch nur einen Raumtemperaturfühler, und der ist am 
Raumcontroller (RCxxx), oder?

Gruß
IngoF

[Martin B. (martin_b13)]

Ingo F. schrieb:
> Martin Berger schrieb:
>> Immer nach dem Telegramm
>> source 0x08, dest 0x00, type 0x18, offset 0
>> ist die WWtemperatur bei -3200°C
>> bei einem Telegramm
>> source 0x08, dest 0x00, type 0x34, offset 0
>> wird die WWtemperatur hingegen richtig berechnet.
>
> Das Telegramm 0x18 kommt von der Brennersteuerung. Diese scheint keine
> Warmwassertemperatur zu haben (0x8000 wenn nicht vorhanden = -3276,8°C)

Komisch, der WWfühler ist bei mir direkt am UBA/MC10 angeschlossen.

> Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das
> müsste vermutlich am besten in den EMS-Collector, oder?

Das sehe ich auch so. Vielleicht kann das jemand (Danny?) in den 
EMS-Collector basteln der mehr Ahnung von C hat als ich. ;-)

> Martin Berger schrieb:
>> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10,
>> dest 0x00, type 0x3e, offset 0
>
> Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller.
>
> Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D
> (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder?
>
> Du hast Doch nur einen Raumtemperaturfühler, und der ist am
> Raumcontroller (RCxxx), oder?

Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den 
Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in 
der die richtige Raumtemperatur enthalten ist. Die am RC30 abgelesene 
Raumtemperatur habe ich schon in Hex umgerechnet und anschließend im Log 
gesucht. Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe 
ich einen Rechen/Denkfehler gemacht?

Grüße
Martin

[Danny B. (maniac103)]

Martin Berger schrieb:
> Ingo F. schrieb:
>> Am besten müssten die Temperaturen mit 0x8000 ignoriert werden. Das
>> müsste vermutlich am besten in den EMS-Collector, oder?
>
> Das sehe ich auch so. Vielleicht kann das jemand (Danny?) in den
> EMS-Collector basteln der mehr Ahnung von C hat als ich. ;-)

Das ist schon drin. Siehe EmsMessage.cpp Zeile 42 bis 48. Du benutzt 
aber schon mein Repo und nicht das von Moosy, oder?

>> Martin Berger schrieb:
>>> Die falsche Raumtemperatur kommt immer nach einem Telegramm source 0x10,
>>> dest 0x00, type 0x3e, offset 0
>>
>> Das ist eigentlich die richtige Raumtemperatur vom Raumcontroller.
>>
>> Woher kommt denn die "andere" Raumtemperatur? Aus dem Telegramm 3D
>> (temperäre Raumtemperatur??). Die dürfte aber kein Messwert sein, oder?
>>
>> Du hast Doch nur einen Raumtemperaturfühler, und der ist am
>> Raumcontroller (RCxxx), oder?
>
> Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den
> Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in
> der die richtige Raumtemperatur enthalten ist. Die am RC30 abgelesene
> Raumtemperatur habe ich schon in Hex umgerechnet und anschließend im Log
> gesucht. Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe
> ich einen Rechen/Denkfehler gemacht?

20.7°C = 207 auf dem EMS = 0x00 0xCF ... Wie kommst du auf 0x08 0x16?

[Ingo F. (ingof)]

Martin Berger schrieb:
> Es gibt nur einen Raumtemperaturfühler im Raumcontroller (RC30). In den
> Logfiles meiner Anlage habe ich leider noch kein Telegramm gefunden in
> der die richtige Raumtemperatur enthalten ist.

OK, dann war das ein Missverständnis. Hatte es so verstanden dass dort 
die richtige Raumtemperatur angezeigt wird. Aber immer nach einem 
bestimmten Telegramm eine falsche Raumtemperatur angezeigt wird.

Martin Berger schrieb:
> Beispiel 20,7°C ist nach Umrechnung in Hex 0x08 0x16 oder habe
> ich einen Rechen/Denkfehler gemacht?

Das Beispiel sollte 0x00 0xcf sein, wie Danny schon geschrieben hat.

[Martin B. (martin_b13)]

Danny Baumann schrieb:
> 20.7°C = 207 auf dem EMS = 0x00 0xCF ... Wie kommst du auf 0x08 0x16?

Ich habe nach 20,7°C = 2070 = 0x08 0x16 gesucht, das war Falsch. Das 
Repo was ich verwende haben hat Dateien mit dem Datum vom 18.12.2014, 
das ist das Repo von dir. ;-)

Hier mal ein Aktuelles Telegramm mit der Falschen WWTemperatur:

MESSAGE[28.01.2015 20:14:59]: source 0x08, dest 0x00, type 0x18, offset 
0, data: 0x2d 0x01 0xfe 0x46 0x46 0x09 0x01 0x35 0x01 0x01 0x6b 0x83 
0x00 0x80 0x00 0x02 0x0c 0xff 0x2d 0x48 0x00 0x00 0xff 0x00 0x10 0x01 
0x44
DATA: Kessel-Solltemperatur = 45 °C
DATA: Kessel-Isttemperatur = 51 °C
DATA: Brenner-Sollwert Modulation = 70 %
DATA: Brenner-Istwert Modulation = 70 %
DATA: Flamme = AN
DATA: Brenner = AN
DATA: Zündung = AUS
DATA: Kessel-Pumpe = AN
DATA: 3-Wege-Ventil auf WW = AUS
DATA: Zirkulation = AUS
DATA: Warmwasser-Isttemperatur = -3200 °C
DATA: Rücklauf-Isttemperatur = nicht verfügbar
DATA: Flammenstrom = 52.4 µA
DATA: Systemdruck = -0.1 bar
DATA: Servicecode = -H
DATA: Fehlercode = 0

Und hier das Telegramm mit einer richtigen WWTemperatur:

MESSAGE[28.01.2015 20:13:14]: source 0x08, dest 0x00, type 0x34, offset 
0, data: 0x0a 0x01 0x6b 0x83 0x00 0x00 0x00 0x00 0x03 0x00 0x00 0x62 
0x8b 0x00 0x06 0x99
DATA: Warmwasser-Solltemperatur = 10 °C
DATA: Warmwasser-Isttemperatur = 36.3 °C
DATA: Warmwasser-Tagbetrieb = AUS
DATA: Warmwasser-Einmalladung = AUS
DATA: Warmwasser-Therm. Desinfektion = AUS
DATA: WW-Bereitung = AUS
DATA: Warmwasser-Nachladung = AUS
DATA: WW-Temperatur OK = AUS
DATA: Warmwasser-Fühler 1 defekt = AUS
DATA: Warmwasser-Fühler 2 defekt = AUS
DATA: Warmwasser-Störung = AUS
DATA: Warmwasser-Störung Desinfektion = AUS
DATA: Zirkulation-Tagbetrieb = AUS
DATA: Zirkulation-Manueller Betrieb = AUS
DATA: Zirkulation = AUS
DATA: Warmwasser-Ladevorgang = AUS
DATA: WW-System-Typ = groß
DATA: Warmwasser-Durchflussmenge = 0 l/min
DATA: WW-Bereitungszeit = 25227 min
DATA: WW-Bereitungen  = 1689

Und leider wird die DB mal mit der Richtigen und mal mit Falschen 
Temperatur beschrieben.

Grüße
Martin

[Martin B. (martin_b13)]

Im Telegramm source 0x08, dest 0x00, type 0x34, offset 0 steckt die 
Wwtemperatur an Position 6 +7 -> 0x01 0x6d = 36,3 °C

Im Telegramm  source 0x08, dest 0x00, type 0x18, offset 0 steckt die 
Wwtemperatur  an Position 14 + 15 -> 0x01 0x6d = 36,3 °C und im Wiki 
steht was von Position 16 + 17

Vielleicht ist da der Fehler, aber warum das nur bei mir auftritt, hmmm

[Ingo F. (ingof)]

Habe jetzt gerade mal bei mir nachgesehen und bei mir stimmt es 
zumindest.
Im Wiki sind die Startadressen als Telegrammoffset angeben. Das wäre das 
Telegrammoffset+5.

poste doch mal Deine Telegramme.

Hier sind meine beiden Telgramme:

Telegramm 0x18:  08 00 18 00 | 3f 02 22 64 3b 09 01 25 60 80 00 02 6f 01 e9 00 27 0c 2d 48 00 c8 ff 02 00 be 
DatenOffset:     -4 -3 -2 -1 |  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25  
TelegrammOffset:  1  2  3  4 |  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

14-15: 0x8000 = Temperatur (DL-Erhitzer?) nicht vorhanden 
16-17: 0x026f =623 => 62,3°C Wassertemperatur
18-19: 0x01e9 =489 -> 48,9°C Rücklauf Temperatur 


Telegramm 0x34:  08 00 34 00 | 3c 02 6f 02 6f 21 00 00 03 ff 01 b9 e1 00 19 bf 2b
DatenOffset:     -4 -3 -2 -1 |  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16
TelegrammOffset:  1  2  3  4 |  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21

6 - 7: 0x026f =623 => 62,3°C Wassertemperatur

[Danny B. (maniac103)]

Ingo F. schrieb:
> Habe jetzt gerade mal bei mir nachgesehen und bei mir stimmt es
> zumindest.
> Im Wiki sind die Startadressen als Telegrammoffset angeben. Das wäre das
> Telegrammoffset+5.
>
> poste doch mal Deine Telegramme.

Hat er doch ;) In deiner Notation:

Telegramm 0x18: 08 00 18 00   2d 01 fe 46 46 09 01 35 01 01 6b 83 00 80 00 02 0c ff 2d 48 00 00 ff 00 10 01 44
DatenOffset:    -4 -3 -2 -1 |  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
TelegrammOffset: 1  2  3  4 |  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

14-15: 0x016b = 363 => Temperatur (DL-Erhitzer?) 36,3°C
16-17: 0x8300 = -32000 => -3200°C Wassertemperatur
18-19: 0x8000 => Rücklauftemperatur nicht vorhanden

Das Problem ist also, dass der Wassertemperaturwert gerade nicht 
0x8000 ist. Ich bin mir allerdings nicht sicher, was die 'draufgeoderte' 
0x300 zu bedeuten hat.
In der Buderus-Doku, die ich habe, sind die Offsets 9 bis 12 leider 
nicht dokumentiert. Die einfachste Lösung wäre wahrscheinlich, diesen 
Wert einfach nicht mehr zu parsen, da ohnehin redundant.

[Ingo F. (ingof)]

Danny Baumann schrieb:
> Hat er doch ;)

Ups ...wie konnte ich das nur übersehen

Danny Baumann schrieb:
> Ich bin mir allerdings nicht sicher, was die 'draufgeoderte'
> 0x300 zu bedeuten hat.

Vielleicht noch eine Information warum der Wert nicht vorhanden ist? 
Also sozusagen eine Fehlermeldung??

Man könnte ja alles mit gesetztem höchstem Bit als nicht vorhanden 
bewerten. Oder zumindest unter -50°C(-500) z.B. Denke nicht dass die 
Außentemperatur soweit sinken wird.

[Juergen O. (juergen_o)]

Ich habe keine Warmwasserbereitung (RC35, MC10). Bei mir taucht auch die 
0x8300 auf. Hier der Debug-Output von meinem ESP-Interface...

[       694.808068  56.821  080  33] 08 00 18 00 3b 02 65 64 64 09 01 35 00 83 00 7d 00 80 00 02 09 ff 2d 48 00 00 ff 00 10 83 00 ? 3b:3b
[       695.905880  96.991  080  33] 08 00 18 00 3b 02 66 64 64 09 01 35 00 83 00 7d 00 80 00 02 09 ff 2d 48 00 00 ff 00 10 83 00 ? c2:c2

[Danny B. (maniac103)]

Juergen O. schrieb:
> Ich habe keine Warmwasserbereitung (RC35, MC10). Bei mir taucht auch die
> 0x8300 auf.

OK, ich schmeiß das Parsen dieses Wertes einfach raus. Wenn WW vorhanden 
ist, steht der Wert ja auch im WW-Monitor-Telegramm.

Martin Berger schrieb:
> Frontend Danny
> Warmwasser Soll: 10°C an Stelle -> 45°C

Ich hab ehrlich gesagt keine Ahnung, was dein UBA da macht. Byte 0 des 
WW-Monitor-Telegramms (0x34) ist (auch laut Buderus-Doku) die 
WW-Solltemperatur, und da steht bei dir 0xa = 10 drin.

> Warmwasser Ist: -3200°C (hier wird Zeitweise der korrekte Wert
> Angezeigt!?)

Siehe oben :)

> Außen gedämpft: keine Anzeige

Die steht im Telegramm 0xa3 (gesendet vom RC30), welches bei dir - aus 
welchen Gründen auch immer - fehlt.

> Raumtemp. IST: 3200°C

Das muss ich nochmal verifizieren. Da steht 0x7d 0x00 drin, was laut 
Buderus-Doku ('Byte1 + (Byte2 * 256)') 12,5°C wäre (ganz schön kalt). Da 
der Algorithmus allerdings für alle Werte mit mehreren Bytes gleich ist, 
dürfte - wenn er falsch wäre - ja gar nix funktionieren.
Ich werd mir das mal anschauen...

EDIT: Passt schon. Die Doku definiert Offset 3 als Byte2 und Offset 4 
als Byte1, d.h. 0x7d * 256 + 0 = 32000 -> 3200°C. Bei mir ist das z.B. 
0x00 0xcb = 20.3°C. Ich habe wiederum keine Ahnung, was dein RC da 
macht...vielleicht ein Bug im RC30; bei mir haben sowohl RC30 als auch 
UBA V2.05.

> Frontend Moosi zusätzlich
> Die Regelart der Anlage wird als Raumtemperatur geführt erkannt, das ist
> aber falsch, tatsächlich ist die Anlage Außentemperaturgefährt. Die
> Heizkurve im Frontend wird deshalb nicht angezeigt.

Der entsprechende Wert (Telegramm 0x3d, Offset 33) ist in deinen 
Telegrammen einfach nicht enthalten. Ich bin mir nicht sicher, was Moosy 
in diesem Fall macht.

> Ich habe mal mit dem Collector ein Logfile erstellt, wäre für eine
> Lösung und Unterstützung sehr Dankbar.

Danke dafür. Ich habe darin noch gesehen, dass der Systemdruck nicht 
richtig ausgewertet wurde, das habe ich gleich mal mit gefixt.

[Ingo F. (ingof)]

Danny Baumann schrieb:
>> Warmwasser Soll: 10°C an Stelle -> 45°C

10°C stehen drin wenn kein Warmwasser bereitet werden soll.
Die 10°C vermutlich nur wegen Frostschutz

Danny Baumann schrieb:
> Die steht im Telegramm 0xa3 (gesendet vom RC30), welches bei dir - aus
> welchen Gründen auch immer - fehlt.

Das hängt davon ab welches "Mauerwerk" man in der Heizung eingestellt 
hat. Das ist ja nur ein berechneter Wert. Es gibt auch irgendwo eine 
Einstellung dass Die Heizung automatisch vorher anspringt dass zur 
eingestellten Zeit auch die Temperatur vorhanden ist.

Kann auch Sein dass es etwas mit der automatischen Sommerbetrieb zu tun 
hat. Mal nachsehen ob und auf welchen Wert das eingestellt ist.

Danny Baumann schrieb:
> Das muss ich nochmal verifizieren. Da steht 0x7d 0x00 drin

Im Wiki hat irgendjemand eingetragen:
Raumtemperatur Ist (0x7d00 für HK abgeschaltet)

[F. F. (pic18f)]

Ingo F. schrieb:
> Im Wiki hat irgendjemand eingetragen:
> Raumtemperatur Ist (0x7d00 für HK abgeschaltet)

Hallo,
wenn ich mich richtig erinnere habe ich diesen Eintrag geschrieben. Bei 
mir wird auch 0x7d00 angezeigt. Die RC30 ist bei mir am Brennwertgerät 
eingebaut, deswegen ist diese nicht mit dem Heizkreis verknüpft.

@jschmied ich habe die Firmware geändert, nun werden die richtigen Werte 
über HTML empfangen.
Kennt sich jemand mit Java-Script aus? Ich habe da keine Ahnung wie ich 
die Seite programmieren kann. Ich möchte die Parameter anklicken, welche 
ich ändern möchte.

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

Hallo Franz,

F. F. schrieb:
> Kennt sich jemand mit Java-Script aus?

Nö, nicht wirklich. ;)
Aber ich glaube was Du suchst findet sich unter [1] oder [2].
Oder vielleicht [3].

Gruß aus der Wetterau
Karl M.

[1] http://de.wikipedia.org/wiki/XMLHttpRequest
[2] http://wiki.selfhtml.org/wiki/JavaScript/API/XMLHttpRequest
[3] http://api.jquery.com/jquery.get/

[jschmied (Gast)]

F. F. schrieb:
> @jschmied ich habe die Firmware geändert, nun werden die richtigen Werte
> über HTML empfangen.
> Kennt sich jemand mit Java-Script aus? Ich habe da keine Ahnung wie ich
> die Seite programmieren kann. Ich möchte die Parameter anklicken, welche
> ich ändern möchte.
Das Schreiben über die JSON Schnittstelle ist bisher nicht richtig in 
der FW drin. Hab auch erstmal keine Zeit, weiterzumachen.

vg

Jürgen

[F. F. (pic18f)]

jschmied schrieb:
> Das Schreiben über die JSON Schnittstelle ist bisher nicht richtig in
> der FW drin

Die Firmware habe ich soweit geändert, sie funktioniert. Nur mit Html 
und Java-Script kenne ich mich nicht aus.
Ich lade demnächst meine aktuelle Version hoch.

Viele Grüße
Franz

[Maarten H (Gast)]

With great help of Danny and Ingo I now got the ems-ethersex-netio 
running, the basic issue was that I was using a 644 i.s.o. 644P w/o 
second UART, so all others where okay, but the system was dead.

I also follwed the 
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io"; to 
setup a BananaPI environment for the collector, MySQL, Lighttpd, etc....
When I run the command "collectord -u ems -p geheim -f -d all 
tcp:192.168.xxx.xxx:7950" I see indeed the EMS messages tanzen auf das 
schirm. I tried to make the required init and default setting in order 
to run from booting.
But I'm notsure the collectord is really running and putting data in a 
MySQL database. I tried to telnet from my Windows-7 PC "telnet 
192.168.1.6 7777" but the system answers there is no connection to the 
host on this port.
I tried root> collectord status, I get no error message nor a reaction.

How to check that the Collectord is really capturing messages and 
storing them in MySQL ?

Thanks Maarten

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

Hello Maarten,

Maarten H schrieb:
> ... the collectord is really running and putting data in a
> MySQL database ...

from your Bananas console, please try:

root@banana: top
you see all active processes. There schould be "collectord" and 
"mysqld".
if "mysqld" exists, try next command:

root@banana: mysqld -u "databasename" -p
now enter your password, you'll get the mysql-console:

at mysql> enter:
use ems_data;
show tables;

you should see the tables structure of your db

now enter:
select * from numeric_data

if there is data, you're fine.
if not, check databases sanity.

to quit mysql, insert "exit".


> ... telnet 192.168.1.6 7777 ...

afaik telnet only works on localhost.

so, from your bananas console try:
root@banana: telnet localhost 7777

if the collectord is running correctly, you should see some lines, now 
try: "help" and have fun.

hth'n greets
Karl M.

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

Hallo Franz,

F. F. schrieb:
> Ich möchte die Parameter anklicken, welche ich ändern möchte.

Du kennst Moosys Frontend?!
https://github.com/moosy

Gruß in die Berge! ;-)
Karl M.

[Danny B. (maniac103)]

Maarten H schrieb:
> But I'm notsure the collectord is really running and putting data in a
> MySQL database. I tried to telnet from my Windows-7 PC "telnet
> 192.168.1.6 7777" but the system answers there is no connection to the
> host on this port.

For that, you need to pass the parameter '-C 7777'.

> How to check that the Collectord is really capturing messages and
> storing them in MySQL ?

There are a couple of options:
- ps, as mentioned by Karl
- let the daemon log into a file and check that file for new entries: 
'-d all=foo.log'
- check the database contents ;)

[Maarten H (Gast)]

Dear Karl,


With "top" I see mysql, but not collectord

top
When I run the mysqld I get:

bananapi@maarten ~ $ mysqld -u ems -p
150130 21:22:34 [Warning] Using unique option prefix key_buffer instead 
of key_b     uffer_size is deprecated and will be removed in a future 
release. Please use the      full name instead.
150130 21:22:34 [Warning] Ignoring user change to 'ems' because the user 
was set      to 'mysql' earlier on the command line

150130 21:22:34 [Warning] Can't create test file 
/var/lib/mysql/maarten.lower-te     st
150130 21:22:34 [Warning] Can't create test file 
/var/lib/mysql/maarten.lower-te     st
mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13)
150130 21:22:34 [ERROR] Aborting

150130 21:22:34 [Note] mysqld: Shutdown complete

bananapi@maarten ~ $ collectord -h     was still working

So first I should get collectord running from booting
I see:
bananapi@maarten /etc/init.d $ ls -l ems-collector
-rwxr-xr-x 1 root root 1883 Jan 29 22:07 ems-collector

In this file:
PROGNAME="collectord"
PROG="/usr/local/sbin/$PROGNAME"
DESCR="EMS collector daemon"

Collectord is in this directory:
bananapi@maarten /usr/local/sbin $ ls -l collectord
-rwxr-xr-x 1 root staff 791487 Jan 30 21:38 collectord

The default:
bananapi@maarten /etc/default $ ls -l ems-collector
-rw-r--r-- 1 root root 339 Jan 29 22:25 ems-collector

So concluding: I get the impression collectord is not running from 
booting


Many thanks Maarten

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

Hi again,

> Ignoring user change to 'ems' because the user
> was set to 'mysql' earlier on the command line

You added user "ems" to the db?
Please check:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#mysql_benutzer_anlegen


> /etc/default/ems-collector

what is the content of that file?

You'll get it running! :-)

Greets
Karl M.

[Maarten H (Gast)]

Hi Karl,


Thanks for helping, I indeed really hope to get it working!!!!

Yes as I made the change to the db, in fact I copied the log:
bananapi@maarten ~ $ sudo mysql -u root -p
Enter password:pa0mhe
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 45
Server version: 5.5.40-0+wheezy1 (Debian)

Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.

mysql> select password('my_PW');
+-------------------------------------------+
| password('my_PW')                        |
+-------------------------------------------+
| *FAA663E23C9CA3A6918059359F95422DC1FA61DA |
+-------------------------------------------+
1 row in set (0.00 sec)


mysql> create user ems identified by password 
'*FAA663E23C9CA3A6918059359F95422DC1FA61Query OK, 0 rows affected (0.00 
sec)
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL ON ems_data.* TO 'ems'@'%';
Query OK, 0 rows affected (0.00 sec)



Content of "/etc/default/ems-collector"
# Defaults file for EMS collector daemon
# This is a POSIX shell fragment

# config file location
CONFIGFILE="/etc/ems-collector.conf"

# Serial device file
SERIALDEVICE="/dev/ttyUSB0"

# Where to put the PID file
PIDFILE="/var/run/ems-collector.pid"

# Other options
OPTIONS="-C 7777 -D 7778 -u ems -p my_PW -r 60 tcp:192.168.1.5:7950"


Thanks again a lot Maarten

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

Hi Maarten;

> # config file location
> CONFIGFILE="/etc/ems-collector.conf"

you may comment out this last line. All config is done within here.

> # Serial device file
> SERIALDEVICE="/dev/ttyUSB0"

you have to comment out last line, cause you're talking tcp.

> tcp:192.168.1.5:7950

912.168.1.5 is the ip of your netio with ethersex?!

Restart the collectord and have a look at your db, whether or not all is 
working and showing tables and data.

Yes, you'll succeed!

Greets to Belgium
Karl M.

[F. F. (pic18f)]

Karl M. W. schrieb:
> Du kennst Moosys Frontend?!
> https://github.com/moosy

Danke, Karl diese Seite kannte ich noch nicht. Ich weiß aber nicht, in 
wieweit dies mit meiner Firmware (JSON) zusammenpaßt.

viele Grüße an die Wetterau, bin morgen wieder da. :-)
Franz

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

Hallo Franz,

> Ich weiß aber nicht, in
> wieweit dies mit meiner Firmware (JSON) zusammenpaßt.

Falls ich Jürgen richtig verstanden habe, sollte das funken!

Aus dem Wiki:

N.b.: Selbst Ingos EMS-GW kann mit der Firmware 2.1.1
und einem ENC28J60 Netzwerkmodul verwendet werden.
So kann man auch über das EMS-GW das neue Frontend
von Moosy benutzen.

Gute Reise und genieße die gesunde Luft in Bad Nauheim!

Gruß
Karl M.

[Maarten H. (maarten_h)]

Dear Karl and Danny,


Yes indeed my ethersex AVR is at 192.168.1.5:7950
collectord -u ems -p "My_PW" -f -d all tcp:192.168.1.5:7950 runs fine I 
can see the EMS messages in this case.

etc/default/ems-collector:
# config file location
# CONFIGFILE="/etc/ems-collector.conf"

# Serial device file
# SERIALDEVICE="/dev/ttyUSB0"


I gave a Reboot,

I cheked with >top but nothing present from collectord, also not with 
telnet.
I tried to start collectord:

bananapi@maarten ~ $ collectord start
Exception: Cannot open pidfile '/var/run/collectord.pid': Permission 
denied
bananapi@maarten ~ $ sudo collectord start
[sudo] password for bananapi:
Exception: Access denied for user 'root'@'localhost' (using password: 
NO)


The I tried to check the db:

bananapi@maarten ~ $ mysqld -u ems -p
150131 12:50:32 [Warning] Using unique option prefix key_buffer instead 
of
key_buffer_size is deprecated and will be removed in a future release.
Please use the full name instead.
150131 12:50:32 [Warning] Ignoring user change to 'ems' because the user 
was set to 'mysql' earlier on the command line
150131 12:50:32 [Warning] Can't create test file 
/var/lib/mysql/maarten.lower-test
150131 12:50:32 [Warning] Can't create test file 
/var/lib/mysql/maarten.lower-test
mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13)
150131 12:50:32 [ERROR] Aborting

150131 12:50:32 [Note] mysqld: Shutdown complete


"My concluding":
collectord: is not starting, perhaps someting wrong with users and 
permissions ?, I'm surely not very experienced with Linux.
mysqld: is started but still having problems.


Thanks a lot both (Karl, Danny) for your support, Maarten

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

Hi again Maarten,

> Cannot open pidfile '/var/run/collectord.pid': Permission

Name and path of the Pidfile in the /etc/default/ems-collector must be 
the same as the existing file. E.g.:

root@home:~# ls -l /var/run/ems-collector.pid
-rw-r--r-- 1 root root 4 Jan 31 14:44 /var/run/ems-collector.pid

> bananapi@maarten ~ $ mysqld -u ems -p

Sorry, sorry, sorry, my mistake!
It has to be:

bananapi@maarten ~ $ mysql -u ems -p

Give 'em a new chance! ;-)

Readya
Karl M.

[Martin B. (martin_b13)]

Ich bekomme jetzt die immer die richtige WW Temperatur angezeigt.
Vielen Dank Danny für die Änderung am Collector. ;-)

Die Warmwassersolltemperatur +45°C wird nur während  dem Normalbetrieb 
Angezeigt im Reduziertenbetrieb wird die +10°C Angezeigt, somit ist das 
in Ordnung.

Im HK1 habe ich die Fernbedienung von „Keine“ auf  „RC30“ umgestellt, 
seitdem bekomme ich eine Raumtemperatur (vom Heizraum) angezeigt. Jetzt 
ist auf dem EMS-Bus auch erheblich mehr Betrieb. Allerdings hat sich 
auch das Verhalten meiner Heizanlage geändert, den Raumeinfluss musste 
ich von +3K auf 0K ändern und meine Heizkurve durfte ich 
wiederherstellen. :-P

Fehlt ein Fühler, wird bei meiner Anlage mit 0x8300 oder mit 0x8000 
dargestellt. Abgastemperatur , Warmwasser Temperatur Ist 2. Fühler  etc. 
bei meiner Anlage mit 0x8300.

Telegramm 0x19 TelegrammOffset:18(Dataoffset13) = Betriebszeit komplett 
= Betriebszeit 1 (bzw. bei meinem 2-Stufenbrenner die Betriebszeit der 2 
Stufe).

Telegramm 0x19 TelegrammOffset:21(Dataoffset16) mit 3 Bytes ist die 
Betriebszeit 2 (bei meinem 2-Stufenbrenner die Betriebszeit der 1 
Stufe). ← Das wäre doch was fürs Wiki und dem Collector ;-)

Telegramm 0x3d geht bei meiner Anlage nur bis 
TelegrammOffset:32(Dataoffset27) und somit gibt es auch keine 
Führungsgröße, maximale Vorlauftemperatur  etc. was im Mosys-Frontend 
„Erweiterte Einstellungen“ verwendet wird.

Telegramm 0xa3 mit der gedämpften Außentemperatur habe ich noch nicht 
gesichtet, dafür ein paar andere Telegramme wie 0x20 etc. die im Wiki 
keine Erwählung finden und zum Teil leer oder mit 0x00 gefüllt sind

[Maarten H. (maarten_h)]

Dear Karl,


ems-collector.pid file:
Understood, but how to locate this file ? It is not in  /var/run

bananapi@maarten /var/run $ find ems-collector.pid
find: `ems-collector.pid': No such file or directory

mysql, I re-tried:
bananapi@maarten ~ $ mysql -u ems -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 42
Server version: 5.5.41-0+wheezy1 (Debian)

Copyright (c) 2000, 2014, Oracle . All rights reserved.

Oracle is a registered trademark of Oracle Corporation Other names may 
be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input 
statement.

mysql> use ems_data
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables
    -> *
    -> \q

Not sure, but I don't think this was the right feedback from the db ?


Thanks again Maarten

[Maarten H. (maarten_h)]

Dear Karl,


I did the experiments you suggested:

bananapi@maarten ~ $sudo touch /var/run/collectord.pid
bananapi@maarten ~ $ service ems-collector restart
[warn] Stopping EMS collector daemon: collectord already stopped 
(warning).
[....] Starting EMS collector daemon: collectordterminate called after 
throwing an instance of 
'boost::exception_detail::clone_impl<boost::exception_detail::error_info 
_injector<boost::program_options::invalid_command_line_syntax>  >' 
what():  required parameter is missing in 'config-file'
Aborted
 failed!
bananapi@maarten ~ $

Something wrong with the config-file ?

# Defaults file for EMS collector daemon
# This is a POSIX shell fragment

# config file location
#CONFIGFILE="/etc/ems-collector.conf"

# Serial device file
# SERIALDEVICE="/dev/ttyUSB0"

# Where to put the PID file
PIDFILE="/var/run/ems-collector.pid"

# Other options
OPTIONS="-C 7777 -D 7778 -u ems -p xxxxx -r 60 tcp:192.168.1.5:7950"



Thanks again Maarten-

[Maarten H (Gast)]

Dear All,



With help of Ingo, Danny and Karl I made big steps forward. Now the 
ems-collector service is running and the MySQL db filled. I can Telnet 
and see the db.
Also the lighttpd webserver is running standalone and I can read the 
default php "Hello world" page.

Next I hope to setup Danny's Webpage. I loaded the "webpage" files into 
/var/www, however I'm missing and index.php file ?
Is there somewhere an Install procedure available ?


Thanks in advance and Best regards Maarten

[Danny B. (maniac103)]

Maarten H schrieb:
> Next I hope to setup Danny's Webpage. I loaded the "webpage" files into
> /var/www, however I'm missing and index.php file ?
> Is there somewhere an Install procedure available ?

There is no index.php in my pages. I reference them directly and usually 
use status.php as entry point. Symlinking status.php to index.php 
probably also works.

[Maarten H (Gast)]

Hi Danny,



Thanks,

I copied all your webpage files intor /var/www
I renamed status.php into index.php.

When I access the webpage with my Firefox browser I get a complete 
"light blue" page, and with IE an error HTTP 500 internal server error.



Thanks Maarten

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

Hi Maarten,

> "light blue" page, and with IE an error HTTP 500 internal server error.

You know this page:
http://www.penguintutor.com/linux/light-webserver

hth'n greets
Karl M.

[Maarten H (Gast)]

Hi Karl,


> You know this page:
> http://www.penguintutor.com/linux/light-webserver
Yes indeed I followed this very good tutorial, including the PHP setup, 
and testpage they gave. This worked fine.

But with Danny's page it is going wrong, I think perhaps that I should 
not Copy the files to /var/www but somewhere else ?
I also tried to make a symlink : ls -l 
/home/bananapi/ems-collector-master/webpage/status.php But also w/o 
success.
The "light blue" pages is titled "Heizung" and when I look to source in 
my browser it is Danny's status.php


Best regards Maarten

[Danny B. (maniac103)]

Maarten H schrieb:
> But with Danny's page it is going wrong, I think perhaps that I should
> not Copy the files to /var/www but somewhere else?

No, the fact that you can access the page shows it's in the correct 
place.

> The "light blue" pages is titled "Heizung" and when I look to source in
> my browser it is Danny's status.php

This sounds like there's some issue with the php interpreter. The web 
server should do an error log (e.g. for apache it's in 
/var/log/apache2/error.log) that should give an idea of what exactly is 
wrong.

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

ReHi Maarten,

> ... PHP setup and testpage ...

PHP is working?!
Tried the typical test.php?

---snip---
<html>
<head>
<title> PHP Test Script </title>
</head>
<body>
<?php
phpinfo( );
?>
</body>
</html>
---snap---

What's about the rights for the webserver files, are they set to 
"www-data"?

Greets to Vlaanderen
Karl M.

[Maarten H (Gast)]

Hi Karl,


Yes I followed exactly the in the penguingtutor metioned file rights, ad 
this gave no errors, also "your" testpage is working see attachment.


Maarten

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

Hi Maarten,

ok, php is working!

As Danny told, what is "/var/log/lighttpd/error.log" saying?

Groetjes
Karl M.

[Maarten H (Gast)]

Hi Karl,



I captured the following from the error.log

2015-02-02 21:16:15: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal 
error:  Uncaug$
Stack trace:
#0 /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc(6): 
PDO->__con$
#1 /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc(24): 
open_db()
#2 /home/bananapi/ems-collector-master/webpage/index.php(27): 
get_current_sensor_v$
#3 {main}
  thrown in 
/home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc on li$




Thanks again Maarten

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

Hi Maarten,

> /home/bananapi/ems-collector-master/webpage/sensor_utils.php.inc

seems, your www files are not in the www-directory??

But sorry for rest of this evening, got an old mate over here.
Some beers are waiting. ;~)

Readya
Karl M.

[Maarten H (Gast)]

Hi Karl,


Prosit.


All Danny's webpage files are both in /var/www and in 
/home/bananapi/emc-collector-master/webpage
And I have a symlink from /var/www/index.php to /var/www/status.php


Bye, Maarten

[Maarten H (Gast)]

Danny, Karl,


What I see in the Errorlog is that "sensor_utils.php.inc" can't access 
the "ems_data" db in MySQL.

When I do the manual:
mysql> use ems_data;
mysql> show tables;
mysql> select * from numeric_data;

It works, any idea what could be wrong ?


Best regards Maarten

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

Hi Maarten,

> "sensor_utils.php.inc" can't access
> the "ems_data" db in MySQL.

File rights??

Please show the first 10 rows of "sensor_utils.php.inc"

Readya
Karl M.

[Maarten H (Gast)]

Hi Karl,



Beginning my "sensor_utils.php.inc" file


<?php

include 'constants.php.inc';

function open_db() {
  return new PDO('mysql:dbname=ems_data;host=localhost', 'emsdata', 
'emsdata');
}

function format_value($row) {
  $value = (float) $row->value;
  if ($row->reading_type == ReadingTypeTime && $row->unit == "min") {
    $hours = (int) floor($value / 60);
    $mins = (int) ($value - 60 * $hours);
    if ($hours > 0) {
      return sprintf("%dh %dmin", $hours, $mins);
    }
  }

I was thinking: Can it be something with file permissions ?, I see the 
"owner" of the db is "mysql" , this is logic, but can the php access 
this ?


Best regards Maarten

[Danny B. (maniac103)]

The last 2 parameters of the 'new PDO...' line are the DB user name and 
password. Do those match what you've set up?

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

Hi Maarten,

> return new PDO('mysql:dbname=ems_data;host=localhost',
> 'emsdata','emsdata');

first 'emsdata' is 'your_dbuser',
second 'emsdata'  'your_dbpass'.

hth'n greets
Karl M.

* Danny ist deutlich schneller! ;-)

[Maarten H (Gast)]

Hi Karl,



News from Vlaanderen, however Still not there


Error.log lighttpd:
2015-02-04 22:19:35: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal 
error:  Unc$
Stack trace:
#0 /srv/www/sensor_utils.php.inc(6): 
PDO->__construct('mysql:dbname=em...', 'em$
#1 /srv/www/sensor_utils.php.inc(24): open_db()
#2 /srv/www/status.php(27): get_current_sensor_values()
#3 {main}
  thrown in /srv/www/sensor_utils.php.inc on line 6

2015-02-04 22:19:41: (server.c.1558) server stopped by UID = 0 PID = 
3262

My line (6) ensor_utils.php.inc:
  return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 
'my_pwd');



Best regards Maarten

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

... sorry, no idea at the moment. (Danny?)

Will you show rows 4 to 8 again, please.

[Maarten H (Gast)]

Hi Karl,



Here sensor_utils.php.inc line 4..8

function open_db() {
  return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 
'my_pwd');
}

I was not aware this modification of adding user and pw, is there 
anywhere a install procedure of this webpage, as I perhaps miss also 
other settings.




Best regards Maarten

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

Hi Maarten,

> Here sensor_utils.php.inc line 4..8
seems perfect!

> is there a install procedure of this webpage
Know none.
Perhaps you will (have to) go the hard way through all files and check 
all the stuff.

Readya
Karl M.

[Maarten H (Gast)]

Hi Karl,


I gave up on the old image and decided to start with a new, completely 
fresh setting_up everthing, and...... it is working, I can read Danny's 
webpage, still not with graphs, but that is for later.

my Buderus setup is:
MC10 / UBA Brenner (ol type) (We have here no gas close to my home)
BC10
RC35
Warmwater boiler



Now I noticed a few strange items:

The "warmwasser IST" temperature is mostly indicated as 3200.0C, 
sometimes I get the right temperature, I see the system uses: source 
0x08 type 0x18 offset 16, this is indeed 3200, but only in source 0x08 
type 0x34 offset 6 is the right warmwater actual temperature. Is this 
easy to change ?

My system also measures the "abgastemperature", I can see this on my 
RC35, but not on in the MySQL data, this is transmitted in source 0x08 
type 0x19, this message is also used for other information presented in 
the webpage, is this possible to add ?

I added a log file from my collectord

Do you have an idea?

Best regards Maarten

[Danny B. (maniac103)]

Maarten H schrieb:
> The "warmwasser IST" temperature is mostly indicated as 3200.0C,
> sometimes I get the right temperature, I see the system uses: source
> 0x08 type 0x18 offset 16, this is indeed 3200, but only in source 0x08
> type 0x34 offset 6 is the right warmwater actual temperature. Is this
> easy to change ?

Yes. It's so easy that I actually already did it, see a few posts above. 
If you're using my repo, try a git pull, otherwise try using my repo. :)
>
> My system also measures the "abgastemperature", I can see this on my
> RC35, but not on in the MySQL data, this is transmitted in source 0x08
> type 0x19, this message is also used for other information presented in
> the webpage, is this possible to add ?

Yes, sure. I'll add it.

[Maarten H (Gast)]

Hi Danny,



Very nice, I was very bussy with getting the basics running, so I didn't 
look carefully to other posts. I will upload your latest repo tomorrow.

As you can understand I'm very happy that it is finally running, now I 
can enjoy the nice work you and your friends created.

Short question:
to get the graphs running, I see the phyton file "ems-gen-graphs.py", 
and I also see in "day.php" the graph's are called, but what to do with 
the phyton file ?, how to execute it ? where and when ?




Thanks a lot Maarten

[Ingo F. (ingof)]

Hallo Danny,

ich habe keinen Raspi und würde gerne den collectord auf meiner Synology 
Diskstation laufen lassen.

Ich hatte mir gedacht meinen EMS-Gateway als Verbindung zwischen EMS-Bus 
und Diskstation zu nehmen.

Also benötige ich wohl den Framer nicht, oder? der läuft ja dann auf dem 
NetIO?!

Meine erste Frage richtet sich erst mal an die Boost-Bibliothek.
WO kann man die Quellen dazu finden? Denke ja dass ich die dann auch 
noch erst kompilieren muss.

Weitere Bibliotheken hast Du ja nicht verwendet, oder?

Habe mal versucht eine einzelne Datei zu kompilieren. Die Datei mit den 
wenigsten importen scheint EmsMessage.cpp zu sein. Aber es hagelt nur 
Fehler.... Fängt scho mit "EmsMessage.cpp:25:28: error: 
boost/format.hpp: No such file or directory" an.

Darf ich Dich eventuell mal per Mail "belästigen"?

Gruß
Ingo

Edit:
hänge einfach mal das ergebnis des ersten kompilier Versuch an....

[Norbert S. (norbert)]

Hallo Ingo,

du scheinst nicht alle Abhängigkeiten z.B. libboost-all-dev installiert 
zu haben.

Gruss
Norbert

[Ingo F. (ingof)]

Hallo Norbert,

inzwischen bin ich schon etwas weiter.
Boost konnte ich über ipkg nachinstallieren (boost-iostreams)

Das Problem sind jetzt MySQL++-Imports.

MySQL++ gibt es nicht in IPKG für die Diskstation. Habe mal versucht die 
Sourcen für den C++Connector herunterzuladen und zu kompilieren.

Bekomme es aber irgendwie nicht hin.

make hat keine Lust weil es wohl keine Makefiles gibt. Oder zumindest 
nur welche für CMake?!

Gruß
Ingo

Edit:
CMake ist wohl eher für CrossCompiling. Es muss wohl auch irgendwie mit 
Make gehen, habe aber keinen blassen schimmer.

Google konnte mir aber noch nicht weiterhelfen

[Maarten H (Gast)]

Hi Danny,


In the mean time I have the graphs --> GREAT


Thanks a lot Maarten

[Ingo F. (ingof)]

Irgendwie komme ich nicht weiter beim kompilieren des mySQL Connector 
C++

Alle anderen Bibliotheken scheint es wohl zu geben nur nicht den 
"MySQL-Connector-C++"

Den collectord würde ich bestimmt kompiliert bekommen.

Das Bibliotheken-kompilieren scheint meinen Horizont zu übersteigen.

Ergebnis zwei komplette Tage umsonst.

Denke es wird wohl besser sein die Idee für ein paar Jahre 
zurückzustellen oder die Idee ganz zu begraben.

Gruß
Ingo

[Juergen O. (juergen_o)]

Hallo Ingo,
ich finde die Idee mit der Synology als collectod ganz smart und habe 
auch schon mit dem Gedanken gespielt, diesen für die Syno zu bauen.

Welches Synology-Modell hast du denn?

[IngoF (Gast)]

Habe die DS212+ und DS415+. Das kompilieren klappt auf beiden erst mal 
ganz gut. Natürlich hagelt es Fehlermeldungen, Aber der größte Teil wird 
weg sein wenn die MySQLConnector-Bibliotheken erst mal da sein sollte.

Gruß
Ingo

[Juergen O. (juergen_o)]

Hab' noch ne paar Fragen zum EMS-Protokol...
ACK (01 BRK) und NACK (04 BRK)
- werden diese nur für die Datensätze des PC-Modules (0x0B) generiert?
  Ich konnte keine diesbezüglichen Msgs in meinen Logs finden
- byteweises Versenden mit Echo vom Master
  Gilt dies auch ausschließlich für das PC-Modul? Meine Logs hier
  (0x08, 0x09, 0x10) zeigen kein derartiges Verhalten
- Wie unterscheide ich (theoretisch) den Poll-Response eines 
RS232-Gateways (0x04) und einem NACK?

Gateway (NETIO, PIC)
Werden ACK und NACK an den collectord durchgereicht oder vom Gateway 
behandelt? (Bspw. Resend bei NACK)

Wie werden Framing Errors bzw Collisions vom Gateway (PIC, NETIO) 
behandelt, wenn Daten zu senden sind? Datensatz nach Timeout nochmal 
versenden? Auf NACK vom Master warten? Oder einfach den Versuch 
"vergessen"?

Uhrzeit/Datum
Kann die Uhrzeit der RCxx jetzt gesetzt werden bzw. sind die Telegramme 
des Zeitmodules bekannt?

Wiki...
Anscheinend ist in der Erklärung der RCTempMessage etwas falsch - oder 
meine Heizung macht was anders...

10 00 a3 00 07 01 00 01 3a 01 40 01 40 83 00 83 00 ? ee:ee

Die "gedämpfte Außentemperatur" ist im Wiki als 2-Byte  Wert 
beschrieben.
Das würde sich jedoch auf die Endianess der Temperaturen ab Pos. 8 
auswirken...

[IngoF (Gast)]

Juergen O. schrieb:
> Hab' noch ne paar Fragen zum EMS-Protokol...
> ACK (01 BRK) und NACK (04 BRK)

NACK un ACK werden nur auf Nachrichten gesendet die Werte verändern.
Bei Abfragen (MSB von Zieladresse gesetzt) oder bei Telegrammen an Alle 
Ziel 0x00) werden diese auch nicht gesendet.

Juergen O. schrieb:
> Gilt dies auch ausschließlich für das PC-Modul?
Das betrifft eigentlich alle Telegramme.

Juergen O. schrieb:
> Werden ACK und NACK an den collectord durchgereicht oder vom Gateway
> behandelt?

Beim EMS-Gateway werden diese einfach weitergeleitet. Weiss jetzt nicht 
mehr ob ein automatisches Resend kommt. Bin mir relativ sicher dass das 
nicht passiert.

Juergen O. schrieb:
> Uhrzeit/Datum
> Kann die Uhrzeit der RCxx jetzt gesetzt werden bzw. sind die Telegramme
> des Zeitmodules bekannt?

Das Telegramm 0x06 von der RCxxx ist ja bekannt. Habe mal versucht einen 
Wert zu ändern (Wochentag) Kann aber auch daran liegen dass der 
Wochentag ja eigentlich schon durch das Datum vorgegeben wurde und 
deswegen nicht geändert wurde. Vielleicht liegt es ja auch daran dass 
das komplette Telegramm gesendet werden muss.

Denke schon dass sich Zeit und Datum ändern lassen.

[Niffko _. (niffko)]

Juergen O. schrieb:
> - byteweises Versenden mit Echo vom Master
>   Gilt dies auch ausschließlich für das PC-Modul? Meine Logs hier
>   (0x08, 0x09, 0x10) zeigen kein derartiges Verhalten

0x08 ist übrigens der Master ;)
Ansonsten gilt, das was Du in Deinen Logs siehst, sind Echos des 
Masters. TX der Module siehst Du nicht, da sie über die 
Strom-Schnittstelle laufen.

Juergen O. schrieb:
> - Wie unterscheide ich (theoretisch) den Poll-Response eines
> RS232-Gateways (0x04) und einem NACK?

Einem Poll-Response geht ein Poll-Request vorraus, einem NACK ein 
Set-Telegramm ;)

Juergen O. schrieb:
> Die "gedämpfte Außentemperatur" ist im Wiki als 2-Byte  Wert
> beschrieben.

Das müsste korrigiert werden. Gedämpfte AT ist signed 8Bit. Ein größerer 
Wertebereich macht keinen Sinn, da ganzzahliger Wert ohne Dezimalstelle.

//Niffko

[Ingo F. (ingof)]

Niffko _ schrieb:
> Das müsste korrigiert werden. Gedämpfte AT ist signed 8Bit. Ein größerer
> Wertebereich macht keinen Sinn, da ganzzahliger Wert ohne Dezimalstelle.

Habe das jetzt geändert. Das Offset müsste ja richtig sein...

Wegen dem Diskstation collectord habe ich mal meine bisherigen Versuche 
als "Anleitung" im Wiki abgelegt. Tipps dazu am besten per mail oder PN.

Dieses Thema hat ja nicht direkt was mit diesem Thread zu tun...

[Juergen O. (juergen_o)]

Stimmt noch nicht ganz... da die gedämpfte Außentemp nur 1Byte hat,
rutschen die folgenden Einträge alle um eine Position nach vorne:

...
10  00  A3  6  0  1  1  2  °C  Flag 1
10  00  A3  7  0  1  1  2  °C  Flag 2
10  00  A3  8  0  2  10  2  °C  Raum-Ist
10  00  A3  10  0  2  10  2  °C  Temperatur 1
10  00  A3  12  0  2  10  2  °C  Temperatur 2
10  00  A3  14  0  2  ?  2  ?  Sensor ?
10  00  A3  16  0  2  ?  2  ?  Sensor ?

Die letzten beiden Sensoren sind bei mir nicht angeklemmt und demzufolge 
"83 00".

[Danny B. (maniac103)]

Juergen O. schrieb:
> Gateway (NETIO, PIC)
> Werden ACK und NACK an den collectord durchgereicht oder vom Gateway
> behandelt? (Bspw. Resend bei NACK)

Mein ethersex-Code reicht die durch, indem er daraus ein Telegramm 
zusammenbastelt. Aus 0x04 wird '<source> 0x0b 0xff 0x04', so dass die 
normale Paketauswertungslogik darauf anspringen kann und erkennt, dass 
es eine Antwort an den 'PC' ist. Der Collector sendet daraufhin eine 
entsprechende Antwort in den Socket (CommandHandler.cpp, Zeile 1126).

> Wie werden Framing Errors bzw Collisions vom Gateway (PIC, NETIO)
> behandelt, wenn Daten zu senden sind? Datensatz nach Timeout nochmal
> versenden? Auf NACK vom Master warten? Oder einfach den Versuch
> "vergessen"?

Wie sollen die Collisions denn passieren? Es wird doch immer nur nach 
expliziter Aufforderung durch den Master gesendet.

[F. F. (pic18f)]

Juergen O. schrieb:
> Uhrzeit/Datum
> Kann die Uhrzeit der RCxx jetzt gesetzt werden bzw. sind die Telegramme
> des Zeitmodules bekannt?

Die Uhrzeit habe ich schon einmal gestellt, das funktioniert.

IngoF schrieb:
> Das Telegramm 0x06 von der RCxxx ist ja bekannt

[Ingo F. (ingof)]

Juergen O. schrieb:
> 10  00  A3  14  0  2  ?  2  ?  Sensor ?
> 10  00  A3  16  0  2  ?  2  ?  Sensor ?
> Die letzten beiden Sensoren sind bei mir nicht angeklemmt und demzufolge
> "83 00".

Die waren im Wiki noch nicht drin... Kann auch sein dass die je nach 
Softwareversion nicht vorhanden sind...

Gruß
Ingo

[Roland (Gast)]

Hi,

der EMS-Collector läuft nach erneutem Kompilieren wunderbar, (musste die 
erstellte executable noch in den sbin ordner kopieren damit die gefunden 
wird). Das PHP Interface macht mir aber kopfzerbrechen. Egal was ich 
aufrufe auf der Hauptseite der Heizungssteuerung ich bekomme keine 
Daten.  Egal ob Protokoll, Statistik usw. Wenn ich den Livestatus 
anklicke erscheint nur der LAdebalken und bleibt bei 10% stehen. Ich 
vermute ein Rechteproblem der php dateien oder ein Problem mit der mysql 
database.

Hat jemand einen Tip wie ich den Fehler rausfinden könnte?

Grüße
Roland

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

Hi Roland,

> ... Fehler rausfinden ...

1. Mal unter "/var/log/lighttpd(bzw. apache2)/error.log" nachschauen.
2. Im *.php script spionieren, was hinter der 10%-Marke des Ladebalkens 
"gefährliches" kommt.
3. Ggf. Pfade anpassen, Rechte setzen (www-data).

hth'n greets
Karl M.

[Roland (Gast)]

@charlie-w,

danke das probier ich mal. Habe grade indie Logdatei geschaut, es sieht 
so aus wie wenn dem Apache ne datei fehlt die in den phpskripten 
aufgerufen wird. Da werd ich mal in die Skripte reinschauen....

[Maarten H (Gast)]

Roland,


Did you check sensor_utils.phh.inc line 6 ?
  return new PDO('mysql:dbname=ems_data;host=localhost', 'ems', 
'yourpwd');


Maarten

[Ingo F. (ingof)]

Hallo Danny,

Nach meinen ganzen vergeblichen compile und Crosscompile-Versuchen für 
die Diskstation brauchte ich dringend eine Erfolgserlebnis.

Also habe ich den collectorD auf einem Laptop kompiliert und 
installiert. Die website-Dateien habe ich in den Apache-WWW-Ordner 
gepackt. Einen symbolischen link auf Status.php habe ich angelegt und 
die IP-Adresse inkl. Benutzernamen und Passwort in der 
*sensor_utils.php.inc* geändert.

Jetzt bekomme ich die Status.php angezeigt mit allen aktuellen Daten.

Allerding ist unten auf der Übersicht Tag/3Tage/Woche/Monat unten nur 
unter der Überschrift Graphen.

die Wörter für die Entwicklung Temperaturen 
*Außen/Raum/Kessel/Warmwasser*

Das ist kein Link.

Ist das OK so, oder sollten dort die Temperaturkurven oder ein Link 
dorthin angezeigt werden?

Muss noch irgendwo was eingestellt sein oder habe ich eventuell eine 
bibliothek oder ähnliches vergessen?

[Danny B. (maniac103)]

Ingo F. schrieb:
> Ist das OK so, oder sollten dort die Temperaturkurven oder ein Link
> dorthin angezeigt werden?

Die Kurven sollten angezeigt werden. Ich lasse dafür regelmäßig (via 
cron) gnuplot Bilder malen. Meine crontab ist hier: 
https://gist.github.com/maniac103/8486528 (Pfade musst du natürlich 
anpassen: /var/tmp/heizung entspricht bei mir <webpageroot>/graphs). Das 
Python-Skript liegt mit im Collector-Repo.

Ich wollte das schon ewig mal auf clientseitiges Malen via flot o.Ä. 
umstellen, aber mir fehlt die Zeit :-/

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

Hi, Ihr Zwei,

Danny Baumann schrieb:
> clientseitiges Malen via flot o.Ä.

schon mal bei Highcharts/Highstock vorbeigeschaut?!
http://www.highcharts.com/stock/demo

Tim Kang zeigt auf seiner Seite ein paar nette Beispiele, wie man Daten 
aus mysql holt und als skalierbare Grafik mit Highcharts/stock 
darstellt.
http://blueflame-software.com/blog/column-chart-with-data-from-mysql-using-highcharts/

Gruß aus der frühlingshaften Wetterau
Karl M.

[Danny B. (maniac103)]

Karl M. W. schrieb:
> Hi, Ihr Zwei,
>
> Danny Baumann schrieb:
>> clientseitiges Malen via flot o.Ä.
>
> schon mal bei Highcharts/Highstock vorbeigeschaut?!
> http://www.highcharts.com/stock/demo
>
> Tim Kang zeigt auf seiner Seite ein paar nette Beispiele, wie man Daten
> aus mysql holt und als skalierbare Grafik mit Highcharts/stock
> darstellt.
> 
http://blueflame-software.com/blog/column-chart-with-data-from-mysql-using-highcharts/

Naja, flot ist ja durchaus ähnlich: http://www.flotcharts.org/
Das Problem ist - v.a. bei Wochen- und Monatsansicht - die Menge der 
Daten: Bei einem Datensatz pro 2 Minuten kommen in einem Monat schon mal 
~20k Datensätze pro Sensor zusammen. Das noch multipliziert mit 4 oder 5 
Sensoren machen den JSON-Blob riesig.
Man müsste sich an der Stelle mal Gedanken über ein sinnvolles 
Datenbankschema machen, das die Daten schon zusammengefasst vorhält 
(z.B. in Stundenintervallen), aber das ist Aufwand...

[Ingo F. (ingof)]

Danny Baumann schrieb:
> Bei einem Datensatz pro 2 Minuten kommen in einem Monat schon mal
> ~20k Datensätze pro Sensor zusammen

Es gibt ja mehrere Möglichkeiten Daten zu reduzieren.
Aber einen stündlicher Mittelwert wäre eigentlich einegute Idee.

Dann noch mal ein paar errechnete Mittelwerte oder Summen für einen Tag 
speichern.

Notfalls könnte man auch nur jeden x.ten Wert nehmen. Bei 20000 
Datenwerten einfach jeden 10 Wert nehmen und den Rest ignorieren.

Vielleicht könnte man ja auch pro Kurve einen Zähler einbauen der für 
jede Kurve einzeln hochzählt (8 oder 16 Bit).

Dann könnte man z.B alle Werte rausfiltern die z.B. nur einen durch 10 
teilbaren Wert im Zähler haben.


Dann müsste die nicht aus der MySQL übertragen werden und können dort 
schon rausgefiltert werden.

Gruß
Ingo

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

Ingo F. schrieb:
> Aber einen stündlicher Mittelwert wäre eigentlich eine gute Idee.

Ja, Ingo, das dachte ich auch. Für Innen- und Außentemperatur lasse ich 
auf meinem Raspi-Server zwei separate log-files schreiben. Klar, könnte 
man auch noch in die ems_data einbauen, aber ich bin halt old-school. 
;-)
Die Auswertung macht ein shell-script, "upd_temp_file", s.o., das 
seinerseits jede Stunde von cron ins Rennen geschickt wird.
Die Dateigrößen der generierten files halten sich in Grenzen, seit Mitte 
Oktober 2013 habe ich bis jetzt ca. je 300K gesammelt. Highstock setzt 
das Ganze dann mittels "temp_out.js" (Außentemperaturen) in eine nette 
Graphik um. Highstock ist deshalb mein Favorit, weil man damit jede 
Zeitstrecke individuell darstellen kann, und das im Browser quasi am 
lebenden Objekt.
Im Gegenzug lasse ich die "ems_data" jeden Sonntag auf 30 Tage kürzen, 
damit sie nicht zu fett wird. Das erledigt "shorten_ems_data".

Die übrigen "nicht ems Daten", die ich per 1-wire absammle, speichere 
ich mittels rrdtool in rrd_dbs, die haben eben den Vorteil, datenmäßig 
nicht aus dem Ruder zu laufen.

Gruß
Karl M.

[Maarten H (Gast)]

Hello All,



I have the complete "EMS system" running now, with both Web interfaces 
of Danny and Moosy, including Graphs, translated in Dutch and mofified 
to my "oil heating" properties.

Thanks all who have supported!!!

I found out that (in my case) the "Raumtemperatureinfluss" is halve the 
original value, so 3K on R35 is 1.5K in the collector. I think this 
value (at least in my case) should not have a division 2.

In my case the "Auslegungstemperatur" is set to 65C @ (-17C), the 
presented value on Moosy is 45C.
When I log the Raw data from collectord (not in deamon mode), I don't 
see complete mesaages type 0x3D, so I can't check what is in the RAW 
data.
Also in the RAW data of Moosy's pop-up the value of "HK1 
designtemperature" is not present.
Is there one or other reason this data is not logged ?

I'm specially interested in the "HeizKurve", without roomtemperature 
correction this is easy to calculated, but has anybody already found the 
algoritme (used by Buderus) for the roomtemperature correction ?





Best regards Maarten

[Maarten H (Gast)]

Karl M. W. schrieb:

> Highstock setzt das Ganze dann mittels "temp_out.js" (Außentemperaturen) > in 
eine nette Graphik um.

Very interesting for my extended domotica ambitions, I had a look on the 
Highstock site and these graphs look great. However I not very 
experienced with html or php: do you have also a small expample where 
you call or execute this Graph ?



Thanks in advanced from Damme Belgium, Maarten

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

Dag allemaal,

Maarten H schrieb:
> do you have also a small expample where
> you call or execute this Graph ?

... just have a look at my post under
Beitrag "Re: Faktensammlung Buderus EMS"

It's the "temp_out.js" file doing that job for the temperature outdoor.
To let it fly, you need a tsv logfile as described in and made by 
"upd_temp_file".
Last, you need a *.html/php file with a "<div id=temp_out></div>" where 
"temp_out" is the "renderTo" statement in the "temp_out.js" file.

And for all other temperatures/parameters you just have to change the 
adequate variables. If you want to use mysql instead of tsv-logs, just 
alter the first lines of the *.js file accordingly.

Gruß
Karl M.

[Maarten H (Gast)]

Karl M. W. schrieb:

> Last, you need a *.html/php file with a "<div id=temp_out></div>" where
> "temp_out" is the "renderTo" statement in the "temp_out.js" file.

Thanks, I was looking for this part, the rest was already done.


Thanks again, Maarten

[Ingo F. (ingof)]

Wer kennt sich mit Moosys Frontend aus?

Die Ems-tools werden ja benötigt bevor man sich an das Frontend machen 
kann, oder?

Ich hänge an Punkt 5 der Installationsanleitung:

5. Start the emsclient in the CLI-Subdir. Type
help <enter>.

Wie starte ich den?

Das ist doch eine PHP-Datei, oder?
sobald ich die über Terminal auf dem Linuxrechner starte wird mir nur 
der Quelltext ausgegeben. Habe auch mal versucht die Endung PHP zu 
geben.

Die PHP-Seiten com collectors funktionieren alle problemlos. Auch eine 
Test.php die die Infos ausgibt funktioniert im Browser oder Console

Egal wie ich den emsclient starte wird immer der Quelltext ausgegeben.

Habe mal verschiedene Ordner probiert und Rechte probiert.
Aufruft über Terminal:

./emsclient

 wenn ich im Ordner bin. Oder

http://localhost/emsclient

 im Browser.

Oder ist das keine PHP-Datei? Werden eventuell noch andere Bibliotheken 
oder Pakete als bei den collectord-dateien benötigt?

[Ingo F. (ingof)]

Fehler gefunden.

Mein PHP erwartet

<?php

,nur

<?

 ist ihm zu wenig.

Nach dem ergänzen von php im Quelltext funktioniert jetzt zumindest der 
emsclient aus den emstools.

[Maarten H (Gast)]

Ingo,


I don't think you need emsclient for getting Moosy's Web frontend 
running.
I also first made the emsclient running: I changed the properties into 
executable, I also installed php-cli, then I could simple execute it 
directly, without browser. BUT: now I have the whole Moosy's Wed 
frontend running, and even when I delete emsclient it still works. the 
collectord deamon however should be running.
For the Moosy WEB-FE you have to go through all the files an take care 
all directories are well in place, surely in the config files. Also you 
have to take care www-data is owner-group of most of the directories.


Success and best regards Maarten

[Ingo F. (ingof)]

Maarten H schrieb:
> I don't think you need emsclient for getting Moosy's Web frontend
> running.

Thanks Maarten.

i solved the problem. in the ems-client there was only <? without php. 
After inserting the missing php (<?php) it will work now.

[MySam (Gast)]

Hallo zusammen,

ich habe die Schaltung für den AVR NETIO nachgebaut und nach der 
Anleitung im Wiki in Betrieb genommen -> funktioniert einwandfrei, tolle 
Arbeit habt ihr da geleistet! Als Steuerung kommt eine RC30 zum Einsatz.

Ich habe Moosys Webinterace laufen bzw. das CLI, ebenfalls von Moosy. 
Schaltzeiten kann ich ändern, aber wenn ich die Warmwassertemperatur 
ändere dauert es keine 30 Sekunden bis wieder der am RC30 eingestellte 
Wert erscheint.
Sprich direkt nach dem Ändern bekomme ich über den Bus die veränderte 
Solltemperatur zurück, allerdings springt sie kurz darauf automatisch 
auf den vorherigen Wert. Hat jemand von euch eine Idee woran das liegen 
kann bzw. könnte an seiner Steuerung mal probieren, ob sich das genauso 
verhält?

Grüße, MySam

[IngoF (Gast)]

Könnte mir vorstellen das die RC30 die eingestellte Wassertemperatur 
überprüft und wieder zurück stellt?

Die RC30 ist ja als Wasserbereiter eingestellt, oder?

Was willst Du denn damit erreichen. Du kannst ja auch einmalig die 
Wassertemperatur ändern.

Notfalls kannst Du ja der RC 30 sagen dass sie kein Warmwasser bereitet 
und das dann selber machen?

[IngoF (Gast)]

IngoF schrieb:
> Was willst Du denn damit erreichen. Du kannst ja auch einmalig die
> Wassertemperatur ändern.

...einmalig die Warmwasserbereitung starten

[MySam (Gast)]

Danke für deine schnelle Antwort. Ja, ich vermute dass genau das 
passiert. Ich wollte die Zirkulation manuell starten. Wenn ich an der 
RC30 auf den Knopf "Einmalladung" drücke und die Warmwasser-Temperatur 
weniger als 5 Grad von der Soll-Temperatur abweicht, dann wird die 
Zirkulation für 3 Minuten gestartet ohne das Wasser nachzuheizen.
Daher wollte ich die Soll-Temperatur herabsetzen (um eine Ladung zu 
vermeiden) und über die Einmalladung die Zirkulation starten.

Alternativ kann ich natürlich die Zirkulationspumpe auf Dauerbetrieb 
schalten, dann muss ich aber sicherstellen, dass ich sie nach 3 Minuten 
wieder abschalte. Kann ein Skript machen, muss ich nur sicherstellen, 
dass das zuverlässig funktioniert.
Das ganze dient dazu herauszufinden, wie weit eine bedarfsgerechte 
Zirkulation den Energieverbrauch senkt. Bevor ich nun an den Zapfstellen 
Schalter anbringe, möchte ich gerne erstmal per Smartphone/Tablet testen 
wieviel das ausmacht.

Meine Überlegung ist nur: ich kann Schaltzeiten im RC30 ändern; wenn ich 
eine neue Wassertemperatur setze, dann hätte ich erwartet dass sich der 
eingestellte Wert im RC30 ändert?
Aus der Anleitungs des RC20 (ich habe keinen): "Wenn der Raumcontroller 
RC20 als Fernbedienung für einen Heizkreis installiert ist, wird die 
Warmwasserbereitung und der Betrieb der Zirkulationspumpe für die 
komplette Heizungsanlage mit der Bedieneinheit (z. B. RC30/RC35) 
eingestellt. Die eingestellte Warmwassertemperatur kann mit dem RC30/
RC35 oder dem RC20 geändert werden, es gilt jedoch der Einstellbereich
des RC30/RC35 (maximal 80 °C)."
Somit müsste das über den Bus doch zu machen sein?

[Niffko _. (niffko)]

wie wird denn die ww-solltemperatur mit dem webinterface eigentlich 
gesetzt (hab jetzt keine lust mir das aus dem code herauszupulen).

bei mir mache ich das mit dem 33er telegramm.

welche temperatur hast du denn versucht einzustellen? es gibt eine 
min-begrenzung.

generell gilt: ww-bereitung ist eine funktion des UBA(0x08). sollwerte 
werden "in" den UBA geschrieben. der RC und du seid hier 
gleichberechtigt. der sollwert wird nur einmalig bei änderung gesetzt, 
der RC wird deine änderung also per se nicht korrigieren.

anders sieht es aus, wenn man beispielsweise zirkulationspumpe oder 
einmalladung steuern will. hier setzt der RC minütlich ein eigenes 
telegramm ab (das 35er, wenn ich mich richtig erinnere). will man hier 
nicht "weggebügelt" werden, muss man ebenfalls minütlich senden.


//niffko

[Danny B. (maniac103)]

Niffko _. schrieb:
> wie wird denn die ww-solltemperatur mit dem webinterface eigentlich
> gesetzt (hab jetzt keine lust mir das aus dem code herauszupulen).
>
> bei mir mache ich das mit dem 33er telegramm.

Wenn ich moosy's Code richtig verstehe, macht dieser am Ende 'ww 
temperature <value>', was am Ende Offset 2 in Telegramm 0x33 anpasst.

> welche temperatur hast du denn versucht einzustellen? es gibt eine
> min-begrenzung.

Das sollte der Collector schon entsprechend wegfangen (der hat ein Limit 
30 <= value <= 80).

> anders sieht es aus, wenn man beispielsweise zirkulationspumpe oder
> einmalladung steuern will. hier setzt der RC minütlich ein eigenes
> telegramm ab (das 35er, wenn ich mich richtig erinnere). will man hier
> nicht "weggebügelt" werden, muss man ebenfalls minütlich senden.

Interessant. Zirkulationspumpenkommandos sendet der Collector an die RC, 
da gibt's also kein Problem; Einmalladung wird aber im UBA aktiviert. 
Heißt das, dass die RC die vom Collector angestoßene Einmalladung nach 
einer Minute abbrechen wird? Muss ich glatt mal probieren...

[Niffko _. (niffko)]

@danny
über das 35er teilt der RC dem UBA mit ob ww aktiv/inaktiv, z-pumpe 
aktiv/inaktiv. der telegramminhalt ist logischerweise abhängig von den 
eingestellten zeitprogrammen. einmalladung ist nichts anderes, als dass 
das 35er für 3 min die z-pumpe aktiviert und ggf. auf ww-tagbetrieb 
umschaltet (das dann natürlich nicht nur 3 min.).

//niffko

[MySam (Gast)]

Vielen Dank für die Infos, leider stecke ich bei weitem noch nicht so im 
Detail wie ihr. Ich habe während der Änderung mal die Debug-Daten 
weggeschrieben (siehe Anhang, die interessanten Stellen siehe unten). 
Beim Setzen der WW-Temperatur passiert folgendes (der Versuch fand 
während der Nachtabsenkung statt, tagsüber ist das Verhalten aber 
gleich):
IO: Sending bytes 0x8 0x33 0x2 0x2d
IO: Got bytes 0xaa 0x55 0x4 0x8 0xb 0xff 0x1 0xfd
MESSAGE[17.02.2016 22:27:47]: source 0x08, dest 0x0b, type 0xff, offset 
1, data:
DATA: Unhandled message received(source 0x08, type 0xff).
IO: Sending bytes 0x88 0x33 00 0xa
IO: Got bytes 0xaa 0x55 0xe 0x8 0xb 0x33 00 0x8 0xff 0x2d 0xfb 0xff 0x28 
0xff 0x3 0x46 00 0x7c
MESSAGE[17.02.2016 22:27:49]: source 0x08, dest 0x0b, type 0x33, offset 
0, data: 0x08 0xff 0x2d 0xfb 0xff 0x28 0xff 0x03 0x46 0x00
DATA: Warmwasser-per Kesselschalter freigegeben = AN
DATA: Warmwasser-Temperatureinstellung = 45 °C
DATA: Zirkulation-Schaltpunkte = 3x 3min
DATA: Warmwasser-Desinfektionstemperatur = 70 °C

Daraufhin kommt von Quelle 0x08 noch 2x die gesetzte Temperatur, schon 
30 Sekunden später werden wieder die 50 °C gesendet, die am RC30 gesetzt 
sind.
IO: Got bytes 0xaa 0x55 0xf 0x8 00 0x33 00 0x8 0xff 0x2d 0xfb 0xff 0x28 
0xff 0x3 0x46 00 00 0x77
MESSAGE[17.02.2016 22:27:57]: source 0x08, dest 0x00, type 0x33, offset 
0, data: 0x08 0xff 0x2d 0xfb 0xff 0x28 0xff 0x03 0x46 0x00 0x00
DATA: Warmwasser-per Kesselschalter freigegeben = AN
DATA: Warmwasser-Temperatureinstellung = 45 °C
DATA: Zirkulation-Schaltpunkte = 3x 3min
DATA: Warmwasser-Desinfektionstemperatur = 70 °C
IO: Got bytes 0xaa 0x55 0x5 0x9 0x8 0x33  0x2 0x32 0x2
MESSAGE[17.02.2016 22:27:57]: source 0x09, dest 0x08, type 0x33, offset 
2, data: 0x32
DATA: Unhandled message received(source 0x09, type 0x33).
...
IO: Got bytes 0xaa 0x55 0x6 0x10 0x8 0x35 00 0x1 0x11 0x3d
MESSAGE[17.02.2016 22:28:04]: source 0x10, dest 0x08, type 0x35, offset 
0, data: 0x01 0x11
IO: Got bytes 0xaa 0x55 0xf 0x8 00 0x33 00 0x8 0xff 0x32 0xfb 0xff 0x28 
0xff 0x3 0x46 00 00 0x68
MESSAGE[17.02.2016 22:28:08]: source 0x08, dest 0x00, type 0x33, offset 
0, data: 0x08 0xff 0x32 0xfb 0xff 0x28 0xff 0x03 0x46 0x00 0x00
DATA: Warmwasser-per Kesselschalter freigegeben = AN
DATA: Warmwasser-Temperatureinstellung = 50 °C
DATA: Zirkulation-Schaltpunkte = 3x 3min
DATA: Warmwasser-Desinfektionstemperatur = 70 °C

Die letzten zwei Zeilen mögen interessant sein, denn dort werden von 
BC10 an MC10 die 50 Grad gesendet. Würde ja fast dafür sprechen, dass 
der Drehregler nicht auf "Auto" steht (wo soll der BC10 die Temperatur 
sonst her haben?), was ich mir aber absolut nicht vorstellen kann; da 
die Heizung nicht physisch hier im Haus steht werde ich das morgen 
trotzdem mal prüfen.

[Boxi B. (boxi)]

Hallo,

hat noch jemand einen EMS - RxTx Konverter als PCB (gerne auch schon 
bestückt), dann würde ich die ihm gerne abkaufen.

Boxi

[IngoF (Gast)]

Boxi B. schrieb:
> Hallo,
>
> hat noch jemand einen EMS - RxTx Konverter als PCB (gerne auch schon
> bestückt), dann würde ich die ihm gerne abkaufen.
>
> Boxi

Wäre ganz gut zu wissen um welche es geht. Vermutlich um die 
WLAN-Version, oder?

[Boxi B. (boxi)]

Das kommt drauf an. Was ist denn noch verfügbar. Im einfachsten Fall 
genügt mir der Konverterteil von EMS auf RS232. Da kann ich mir dann den 
mC dranhängen. Was komplett fertiges nehme ich auch gerne.
Oder sowas: 
https://www.mikrocontroller.net/attachment/245669/Selection_028.png

[F. F. (pic18f)]

Hallo, gibt es eine Möglichkeit die fest eingespeicherten Schaltzeiten 
(nicht die Eigenprogramme) abzufragen. Also Morgen, Mittag, 
Abendprogramm...
In welchen Telegrammtype stehen diese? Ich benutze die RC30

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

Hallo Ingo,

die Daten auf:

1. http://ems-gateway.myds.me/dokuwiki/doku.php und
2. http://emswiki.thefischer.net/doku.php

sind inhomogen. Das erzeugt unweigerlich Verwirrung. ?-)

Vielleicht änderst Du den Inhalt der

http://ems-gateway.myds.me/dokuwiki/doku.php

einfach wie folgt:

<?      
  header('Status: 301 Moved Permanently', false, 301);    
  header('Location: http://emswiki.thefischer.net/doku.php');    
  exit();      
?>

Ist wesentlich einfacher, als zwei Wikis mit dem selben Inhalt 
konsistent zu halten. ;-)

Gruß
Karl M.

[IngoF (Gast)]

Danke für den Hinweis.

Karl M. W. schrieb:
> Vielleicht änderst Du den Inhalt der
> http://ems-gateway.myds.me/dokuwiki/doku.php
> einfach wie folgt:

/dokuwiki/dokuphp und doku.php Ist die selbe Datei :-D

Habe die alte Startseite mit einem Link zur neuen Seite versehen.

[Danny B. (maniac103)]

Ich mal mal wieder eine Frage für Niffko ;-)

Ich habe vorhin gerade festgestellt, dass der vom Collector geschriebene 
Wert 'Innentemperatur-Soll' falsch definiert ist: diesen Wert sollte es 
nicht nur 1x geben, sondern 1x pro Heizkreis, da er mit dem 
HK-Monitor-Telegramm mitgeschickt wird. Bislang wird der Wert halt aus 
jedem Telegramm gleich behandelt, was so nicht funktioniert (deshalb war 
mir das auch aufgefallen - bei mir ist er zwischen 0 und der 
eingestellten Temperatur gependelt, weil er nur in HK2 ausgefüllt ist).

Das kann man ja prinzipiell problemlos fixen (mit der Ausnahme, dass 
danach eine kleine Änderung an Moosy's Frontend nötig ist), allerdings 
stellt sich mir die Frage, wie man RC20-Statusmeldungen behandeln muss. 
Daher meine Frage: Wie erkenne ich, welchem Heizkreis die RC20 
zugeordnet ist? Hat die je nach Zuordnung eine andere Busadresse, oder 
steht das mit im Statustelegramm, oder kann man das gar nicht erkennen?

[IngoF (Gast)]

Danny B. schrieb:
> Wie erkenne ich, welchem Heizkreis die RC20
> zugeordnet ist?

Bis Niffko antwortet erst mal meine Meinung:
Ich meine irgendwann mal irgendwo irgendwie aufgeschnappt zu haben dass 
die Busadresse das ist... :-)

[Danny B. (maniac103)]

Wenn dem wirklich so ist, würde ich meine Frage mal noch erweitern: 
welche Busadresse der RC20 entspricht dann welchem HK? ;)

[IngoF (Gast)]

Danny B. schrieb:
> Wenn dem wirklich so ist, würde ich meine Frage mal noch erweitern:
> welche Busadresse der RC20 entspricht dann welchem HK? ;)

Also ich habe mal alle möglichen Bedienungsanleitungen und 
Installationsanleitungen zur RC20, RC30, RC35 und RC300 durchgelesen.

Dort gibt es nur das Beispiel mit zwei Heizkreisen. Und eine RC30/35 und 
eine Fernbedienung RC20.

Demnach ist es wohl nur möglich an einem Heizkreis zu sagen ob sie Die 
RC20 benutzt oder die RC35.

Die RC30/35 sollte es ja wissen an welchem Heizkreis die RC20 
eingestellt ist. Steht es vielleicht in einem Telegramm zum Heizkreis 
drin welchen Controller sie benutzt? Eventuell ist es ja nur ein Bit.
Bis dahin gibt es noch keine Busadressen Probleme.
Nur dann wenn es drei Heizkreise oder mehr gibt.

Hat denn jemand drei oder mehrere Heizkreise an seiner Heizung?
Vielleicht bekommt man es ja so raus.

Denke da kann vermutlich nur Niffko Klarheit schaffen.

[Niffko _. (niffko)]

Danny B. schrieb:
> [...] welche Busadresse der RC20 entspricht dann welchem HK?
gute frage. ich habe hierzu leider weder zahlen noch einen RC20 um es 
auszutesten ...

es ist so, dass am jeweiligen RC20 die zugehörige heizkreisadresse(1-4) 
eingestellt werden muss. ich könnte mir vorstellen, dass hierüber dann 
auch die bus-adresse festgelegt wird. bei adresse "0" würde der RC20 als 
master arbeiten, es darf dann kein RC30/35 vorhanden sein.

ich denke, wir können das nur klären, wenn ein RC20-besitzer mal 
testhalber die mögliche heizkreisadressen einstellt und dann schaut, wie 
die RC20-telegramme aussehen ...


//niffko

[IngoF (Gast)]

Niffko _. schrieb:
> ich denke, wir können das nur klären,

Oder einfac h mal ins Wiki gehen ;-)
http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme#busadressen_ems

Jetzt weissich auch woher meine Vermutungen kamen.
Hatte ja damals so ziemlich alle Adressen abgescannt...

Also 0x17 als Standalone und 0x18 0x1f für Heizkreise 1-8.

[IngoF (Gast)]

IngoF schrieb:
> für Heizkreise 1-8

Zu Heizkreis 1-8 muss ich allerdings sagen dass es eine Vermutung von 
mir ist.
Da es für RC20, Mischer, Warmwasser und Solarmodule genau 8 Adressen 
gibt.

Besser wäre es aber wenn das ein RC20 Benutzer bestätigen könnte.

[Thomas (Gast)]

Hi,

ich versuche gerade, das "moosy"" Webinterface zum Laufen zu bekommen.

Im cli-Verzeichnis wollte ich die emsclient-Datei starten, aber php gab 
mir immer den Dateiinhalt aus. Ursache ist, dass <? anstelle von <?php 
verwendet wurde, was wohl bei meiner PHP-Version nicht mehr zulässig 
ist.

Nächstes Problem war: im include-Verzeichnis werden in den php-Dateien 
überall Dateien mit absolutem Pfad includiert. Z.b. in emsqry.inc: 
require("/emsincludes/config.php");
Der führende Slash sollte imho entfernt werden... oder soll man 
emsincludes unter / ablegen?

(habe nicht viel Ahnung von PHP und lasse ich mich gern korrigieren).

Gruß,
Thomas

[Danny B. (maniac103)]

Thomas schrieb:
> Nächstes Problem war: im include-Verzeichnis werden in den php-Dateien
> überall Dateien mit absolutem Pfad includiert. Z.b. in emsqry.inc:
> require("/emsincludes/config.php");
> Der führende Slash sollte imho entfernt werden... oder soll man
> emsincludes unter / ablegen?

Moosy hat glaub ich letzteres im Sinn gehabt bzw. gemacht. Da mir das 
auch nicht gefallen hat, habe ich bei mir dies Pfadangabe in sämtlichen 
Skripten geändert.

[Danny B. (maniac103)]

IngoF schrieb:
> IngoF schrieb:
>> für Heizkreise 1-8
>
> Zu Heizkreis 1-8 muss ich allerdings sagen dass es eine Vermutung von
> mir ist.
> Da es für RC20, Mischer, Warmwasser und Solarmodule genau 8 Adressen
> gibt.
>
> Besser wäre es aber wenn das ein RC20 Benutzer bestätigen könnte.

Danke, das klingt für mich plausibel. 0x17 würde ich dann auch HK1 
zuordnen.

[Thomas (Gast)]

So... weiter gehts....

In der mconfig.php habe ich noch <? durch <?php ersetzt.
Im include-Verzeichnis habe musste ich aus allen Dateien die Pfade 
"emsincludes" entfernen.

Nun scheint das Webinterface zu funktionieren.
In mehreren Dateien fehlt das <?, das scheint aber nicht zu stören.

In ems-heizkurve.py habe ich geändert:
process.stdin.write("set grid lc rgb '#aaaaaa' lt 1 lw 0,5\n")
process.stdin.write("set grid lc rgb '#aaaaaa' lt 1 lw 0.5\n")
(Komma zu Punkt bei 0,5\n am Ende). Keine Ahnung ob das so stimmt, aber 
er Zeichnet jetzt die Kurve (calcheizkurve.sh manuell als root 
gestartet).

In der config.py habe ich den mysql-Socket angepasst (mysqld anstelle 
von mysql) und in der ems-gen-graphs.py ebenfalls bei 0,5 das Komma 
durch einen Punkt ersetzt.
-> Graphen da :)

Die Scripte kann man auch z.B. alle 5 Minuten per Cron aufrufen, dann 
muss man den Webserver (bei mir apache) keine sudo-Erlaubnis geben.

[IngoF (Gast)]

Thomas schrieb:
> So... weiter gehts....

Genau die selben Probleme hatte ich auch damals... Hatte das in 
irgendeinem Thread aufgelistet und nur auf meinem PC geändert

Habe jetzt einfach mal diese Änderungen auch noch in Meinem Fork (ingof) 
übernommen

[Martin (Gast)]

Hallo,

bei "moosy" EMS-Rohdaten werden bei mir keine Temperaturwerte angezeigt, 
ist das nur bei mir so? Die Felder werden ganz normal gelb aber es 
kommen keine Werte, im Livestatus werden hingegen diverse Temperaturen 
angezeigt.

Gruß
Martin

[Danny B. (maniac103)]

Martin schrieb:
> bei "moosy" EMS-Rohdaten werden bei mir keine Temperaturwerte angezeigt,
> ist das nur bei mir so? Die Felder werden ganz normal gelb aber es
> kommen keine Werte, im Livestatus werden hingegen diverse Temperaturen
> angezeigt.

RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und 
vorherige Diskussion.

BTW, benutzt hier jemand OpenHAB? Wenn ja, besteht Interesse an einer 
Anleitung, wie man den Collector darin einbindet? :)

[IngoF (Gast)]

Danny B. schrieb:
> BTW, benutzt hier jemand OpenHAB? Wenn ja, besteht Interesse an einer
> Anleitung, wie man den Collector darin einbindet? :)

Aber sicher doch.
Lese mich auch schon seit ein paar Tage in openHab ein.

[MySam (Gast)]

Ich bin noch ein kurzes Feedback schuldig beim Problem die 
Warmwassertemperatur zu ändern: ich war erst am Wochenende vor Ort, es 
war tatsächlich am MC10 der Regler auf "50" statt "AUTO" gestanden, dann 
ist es kein Wunder dass es nicht funktioniert. Seitdem er wieder auf 
Auto steht, lässt sich auch die Temperatur wie erwartet einstellen.

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

Danny B. schrieb:

> BTW, benutzt hier jemand OpenHAB? Wenn ja, besteht Interesse an einer
> Anleitung, wie man den Collector darin einbindet? :)

Servus Danny,

... noch nutze ich kein OpenHAB. Neben FHEM wohl eines der Systeme, 
denen eine gewisse Zukunft gegeben scheint. Wobei ich gestehen muss, 
dass mir Perl als Sprache näher ist denn Java. Aber das spielt hier 
keine Rolle!

Wäre es denn nicht grundsätzlich, und insbesondere auch für openHAB, von 
Vorteil, wenn Du EMS in das System "einbauen" würdest. Könnte mir 
vorstellen, dass es einige openHAB User gibt, die auch eine Buderus am 
laufen haben und noch niemals auf dieser Seite hier waren.

Also, auf was wartest Du? ;-)

Gruß aus der frühlingsnahen Wetterau

Karl M.

[Danny B. (maniac103)]

Karl M. W. schrieb:
> ... noch nutze ich kein OpenHAB. Neben FHEM wohl eines der Systeme,
> denen eine gewisse Zukunft gegeben scheint. Wobei ich gestehen muss,
> dass mir Perl als Sprache näher ist denn Java. Aber das spielt hier
> keine Rolle!

Siehst du, mir geht's genau anders herum: mit Perl bin ich noch nie 
warmgeworden, und Java spreche ich ohnehin fließend, weil ich viel für 
Android code. FHEM hatte ich anfangs verwendet, bin aber jetzt beim 
Wechsel auf stärkere Hardware (Wandboard -> NUC) auf OpenHAB 
umgestiegen. Mir scheint, als ob die beiden Projekte den Stereotypen der 
jeweiligen Programmiersprachen entsprechen: FHEM ist eher für 
Entwickler, stellenweise etwas kryptisch und fühlt sich 'basteliger' an, 
während OpenHAB ein typisches Java-Programm ist: braucht viel Speicher, 
ist tendenziell etwas overeingineered, aber sehr flexibel mit einem 
übersichtlichen Konzept untendrunter.

> Wäre es denn nicht grundsätzlich, und insbesondere auch für openHAB, von
> Vorteil, wenn Du EMS in das System "einbauen" würdest. Könnte mir
> vorstellen, dass es einige openHAB User gibt, die auch eine Buderus am
> laufen haben und noch niemals auf dieser Seite hier waren.
>
> Also, auf was wartest Du? ;-)

Das habe ich ernsthaft erwogen, aber dann aus zwei Gründen wieder 
verworfen:
- ich habe keine Lust, noch ein Projekt (hier: OpenHAB-EMS-Addon) zu 
maintainen
- ich habe keine Ahnung, ob die OpenHAB-Leute ein solches Binding 
überhaupt wollen, weil dieses logischerweise den Collector nach sich 
ziehen würde

Stattdessen habe ich den Ansatz gewählt, dem Collector MQTT-Support 
beizubringen. Dafür gibt's ein gutes OpenHAB-Binding, und der 
zusätzliche Daemon (MQTT-Broker, bei mir mosquitto) fällt gegenüber 
OpenHAB kaum ins Gewicht (im Moment bei mir: 272 (!) vs. 5 MB 
Speicherbedarf). Dafür muss man halt nur ein Stück Code pflegen und die 
schlussendlich erreichte Funktionalität ist praktisch identisch. Ich 
werde demnächst mal eine Zusammenfassung in's Wiki schreiben, wie man 
das Ganze aufsetzt und verwendet.

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

Danny B. schrieb:

> ... (Wandboard -> NUC) ...

... posh!

> ... Ich werde demnächst mal eine Zusammenfassung in's Wiki
> schreiben, wie man das Ganze aufsetzt und verwendet.

... awaiting!

[Danny B. (maniac103)]

Karl M. W. schrieb:
> Danny B. schrieb:
>
>> ... (Wandboard -> NUC) ...
>
> ... posh!

;) Nachdem mir inzwischen 4 SD- und Micro SD-Karten im SheevaPlug und 
Wandboard gestorben sind - meistens mit Datenverlust - und wir uns auf 
das Funktionieren des Servers immer mehr verlassen, musste einfach etwas 
stabileres her, das nicht auf SD-Karten als Root-FS angewiesen ist, und 
damit sind so ziemlich alle ARM-Boards raus. Es gibt bestimmt auch 
welche mit eMMC, da ist der Preisunterschied zum NUC aber auch nicht 
mehr so riesig.

>> ... Ich werde demnächst mal eine Zusammenfassung in's Wiki
>> schreiben, wie man das Ganze aufsetzt und verwendet.
>
> ... awaiting!

:) Mal sehen, wann ich dazu komme.

[Martin (Gast)]

Danny B. schrieb:
> RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und
> vorherige Diskussion.

Das ist eine RC35 Version 1.15

[Danny B. (maniac103)]

Martin schrieb:
> Danny B. schrieb:
>> RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und
>> vorherige Diskussion.
>
> Das ist eine RC35 Version 1.15

Hast du Das such dem Collector gesagt? ;) Entweder mit dem 
Kommandozeilenoption --rc-type rc35 oder mit rc-type = rc35 in der 
Konfigurationsdatei.

Edit: Auch wenn es nicht schadet, diese Option anzugeben, sollte es auf 
dein Problem keinen Einfluss haben. Ich muss nochmal schauen, wodurch 
dieses Problem eigentlich ausgelöst wurde...

[Martin (Gast)]

Danny B. schrieb:
> Martin schrieb:
>> Danny B. schrieb:
>>> RC30? Siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" und
>>> vorherige Diskussion.
>>
>> Das ist eine RC35 Version 1.15
>
> Hast du Das such dem Collector gesagt? ;) Entweder mit dem
> Kommandozeilenoption --rc-type rc35 oder mit rc-type = rc35 in der
> Konfigurationsdatei.
>
> Edit: Auch wenn es nicht schadet, diese Option anzugeben, sollte es auf
> dein Problem keinen Einfluss haben. Ich muss nochmal schauen, wodurch
> dieses Problem eigentlich ausgelöst wurde...

Der Fehler ist in der emsdetail.ajax von Mossy, nachdem ich die gegen 
die Version von Danny 
Beitrag "Re: EMS > Adapter > NetIO > Raspi" 
ausgewechselt habe funktionierts. Danke Danny !!

[Danny B. (maniac103)]

Danke für die Rückmeldung, spart mir das Gucken morgen :)
(Ich wusste, dass da was war, konnte mich aber nicht genau erinnern)

[Danny B. (maniac103)]

Karl M. W. schrieb:
> Danny B. schrieb:
>> ... Ich werde demnächst mal eine Zusammenfassung in's Wiki
>> schreiben, wie man das Ganze aufsetzt und verwendet.
>
> ... awaiting!

Ein Anfang: http://emswiki.thefischer.net/doku.php?id=wiki:ems:openhab
Die Zuordnung von Sensoren zu MQTT-Topics muss ich mal noch 
dokumentieren, die muss man sich im Moment aus der Ausgabe von Port 7778 
erschließen. Die Steuerung der Heizung via OpenHAB werde ich später noch 
dokumentieren; ich möchte das vorher erst mal selbst testen ;-)

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

Danny B. schrieb:
> http://emswiki.thefischer.net/doku.php?id=wiki:ems:openhab

Danke Danny! Mal sehen, ob ich das kapiere?-)

[Daniel K. (daniel_k108)]

Hi,

ich habe das KM271 in meine Logamatik 2107 gesteckt und per USR-TCP232-2 
an´s LAN genommen. Ich bekomme nun per C#-Programm folgendes gelesen 
(siehe unten) und habe große Mühe das zu interpretieren. Das, was ihr so 
bekommt, kommt bei mir nicht. Die Standards funktionieren (also eine 02 
gesendet, kommt eine 10 zurück).

Ich sende alle 20 sek. eine 10 um die Daten zu bekommen (ist das die 
richtige Vorgehensweise?)

Das hier bekomme ich (kaum Änderungen und fast immer das Gleiche):

04 00 07 01 00 25 C0 01 10 03 F5
02
04 00 07 01 00 25 C0 01 10 03 F5
02
04 00 07 01 00 25 C0 01 10 03 F5
02
04 00 07 01 00 25 C0 01 10 03 F5
02
00 00 65 09 14 28 02 2A 10 03 6B
02
04 00 07 01 00 25 C0 01 10 03 F5
02
04 00 07 01 00 25 C0 01 10 03 F5
02
04 00 07 01 00 25 C0 01 10 03 F5
02
04 00 07 01 00 25 C0 01 10 03 F5


Was mache ich falsch? Danke, Daniel

[IngoF (Gast)]

Daniel K. schrieb:
> Ich sende alle 20 sek. eine 10 um die Daten zu bekommen (ist das die
> richtige Vorgehensweise?)

Kenne jetzt speziell dieses Modul nicht.
Aber Buderus verwendet zur Kommunikation oft 3964R-Protokoll. Dort steht 
genau beschrieben wie es funktioniert.

Alle 20 Sekunden könnte bedeuten dass eventuell die Daten zwischen zwei 
Abfragen "verloren" gehen...

denke die einzelne 02 gehört noch zum Handshake..

Kenne mich mit dem 2107 Bus überhaupt nicht aus und kann zur 
Telegrammbedeutung wenig sagen. Müsste aber alles am 2107-Thread stehen:
Beitrag "Logamatic 2107 Schnittstelle"

Daniel K. schrieb:
> Das hier bekomme ich (kaum Änderungen und fast immer das Gleiche):

Das könnte daher kommen dass viele Telegramme wegen des 20 Sekunden 
Polling ignoriert werden. Denke es dürfte dann nur alle 40 Sekunden ein 
Telegramm kommen...

[IngoF (Gast)]

Daniel K. schrieb:
> Ich sende alle 20 sek. eine 10

Dann auch beachten dass deshalb die 10 Datenwerte doppelt gesendet 
werden.

[Daniel K. (daniel_k108)]

Genial, Danke euch!

Interval auf 250ms, jetzt klappt es prima!

[Ferdinand S. (sir_bacon)]

Hallo,

Mittlerweile habe ich mir ein Adapter besorgt 
(Beitrag "Re: EMS > Adapter > NetIO > Raspi"). Jetzt möchte ich 
gerne der Software von Danny B. auf eine Raspberry Pi zum laufen 
bekommen. Dazu habe ich noch einige Fragen und hoffentlich kann jemand 
die beantworten.

1. Hardware Anbindung
Kan ich der Platine direkt an der RPI UART anbinden, oder ist es besser 
dies mit eine UART-USB Adapter zu machen?

2. Regler Typ
Momentan habe ich ein Nefit Moduline 300, gleiches model als Buderus 
RC30. Ich möchte aber gerne auch der Außentemperatur mit aufzeichnen. 
Dazu muß ich mir dann ein Sensor und ein andere Regler besorgen, 
entweder der RC35 oder RC300. Funktionieren beide Regler mit der 
EMS-Collector?

3. Installations Anleitung
Ich hab mir diese Thread, der Github 
(https://github.com/maniac103/ems-collector) und der Wiki nachgesehen. 
Habe ich etwas übersehen wenn ich nicht ein detaillierte Anleitung 
gefunden habe? Kann mir jemand Koordinaten geben?

4. Installation
Wegen viele defekte SD-Karten in meine RPI's möchte ich gerne der 
Datenbank und Webseite auf meine Synology machen. Kann ich bei der 
Installation auf eine externe Datenbank verweisen? Kann der Webseite auf 
eine Datenbank der nicht auf 'localhost' legt zugreifen?

So, viele Fragen, ich hoffe es gibt auch antworten ;-)

Gruß, Ferdinand

[Ingo F. (ingof)]

Ferdinand S. schrieb:
> 1. Hardware Anbindung
Die Platine kann weder mit USB oder direkt am Raspi angeschlossen 
werden.
Was mich aber wundert ist dass im Tread dort "Zu Raspberry Pi" im 
Schaltplan steht.?!

Die Platine macht nur eine Umwandlung auf die Serielle Schnittstelle.
Das Problem ist dass dann der Raspberry-Pi jedes Zeichen einzeln abholen 
muss damit das Framing (spezielles Break-Signal) erkannt werden kann.

Es könnte auch in der Software anders verarbeitet werden um das Break 
durch die Datenanalyse nachträglich wieder zu erkennen. Glaub das aber 
nicht.

Der Collector kann auch wohl Daten über die serielle Schnittstelle 
empfangen. Allerdings wird dabei ein spezielles Datenformat erwartet das 
mit dieser Platine wohl nicht funktionieren wird (Break).


> 2. Regler Typ
Der Reglertyp ist dabei egal. Die Außentemperatur wird auch so auf den 
Buss gegeben. Bei der Raumtemperatur wird die Temperatur durch den 
"Regler" gemessen. Das kann also nicht funktionieren.

Der EMS-Collectore kommt mit der RC30 RC300 klar. Dafür wurde er ja 
urscprünglich geschrieben.


> 3. Installations Anleitung
Im Wiki gibt es auch eine Anleitung:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io


> 4. Installation
Denke der collectord sollte kein Problem haben wenn die mysql nicht auf 
dem selben Server liegt. Allerdings müsstest Du dann eventuell auf die 
das PHP-Webinterface verzichten oder das auf dem selben (Web)Server wie 
die MySQL zu packen. Hatte damals keine Verbindung zu einer 
mySQL-Datenbank aufbauen können die nicht auf dem selben Server lag. 
Keine Ahnung ob das php-webinterface überhaupt interessant für Dich ist.

[Danny B. (maniac103)]

Ingo F. schrieb:
> Der Collector kann auch wohl Daten über die serielle Schnittstelle
> empfangen. Allerdings wird dabei ein spezielles Datenformat erwartet das
> mit dieser Platine wohl nicht funktionieren wird (Break).

Richtig. Der Collector erwartet, dass im Bytestream auf der seriellen 
Schnittstelle schon ein Framing vorhanden ist:
0xaa 0x55 <len> <data0> <data1> ... <dataX>

Diese Umwandlung (Break erkennen, Checksumme prüfen, Framing einfügen) 
hat bei mir bislang immer ein Atmega gemacht. Wenn die serielle 
Schnittstelle des Raspi (bzw. die Treiber der selbigen) Breaks erkennen 
kann, könnte man das auch in einen Prozess packen; da müsste mir nur mal 
jemand sagen, wie das geht...hab selber keinen Raspi.

>> 2. Regler Typ
> Der Reglertyp ist dabei egal. Die Außentemperatur wird auch so auf den
> Buss gegeben. Bei der Raumtemperatur wird die Temperatur durch den
> "Regler" gemessen. Das kann also nicht funktionieren.
>
> Der EMS-Collectore kommt mit der RC30 RC300 klar. Dafür wurde er ja
> urscprünglich geschrieben.

Nee, das stimmt so nicht. Er geht mit RC30 und RC35, allerdings nicht 
mit RC300 ... die ist EMS+, und dafür hat noch keiner die Telegramme 
decodiert.

[Ingo F. (ingof)]

Danny B. schrieb:
> Diese Umwandlung (Break erkennen, Checksumme prüfen, Framing einfügen)
> hat bei mir bislang immer ein Atmega gemacht. Wenn die serielle
> Schnittstelle des Raspi (bzw. die Treiber der selbigen) Breaks erkennen
> kann, könnte man das auch in einen Prozess packen; da müsste mir nur mal
> jemand sagen, wie das geht...hab selber keinen Raspi.

Bleibt dann noch die Frage ob der RASPI schnell genug ist jedes Byte 
einzeln abzuholen. Auf einem PC hatte ich es damals nicht geschafft.

Der Raspi ist ja eigentlich nichts anderes als ein "PC"

Beim Polling muss die Antwort ja auch entsprechend schnell kommen.

Sonst kann man nur lauschen und eben so lange auf das Telegramm warten 
bis es kommt. Senden ist dann nicht möglich. Dadurch kann dann auch kein 
Telegramm angefragt werden.

[Danny B. (maniac103)]

Ingo F. schrieb:
> Bleibt dann noch die Frage ob der RASPI schnell genug ist jedes Byte
> einzeln abzuholen. Auf einem PC hatte ich es damals nicht geschafft.

Ja klar ist er das. Die reinkommenden Bytes werden ja mit einem 
Interrupt verarbeitet. Du wolltest das ja aus dem Userspace machen, und 
da habe ich auch Zweifel, ob das Out-of-the-Box funktioniert...daher 
auch der Hinweis auf den Kernel-Treiber.
Die Hardware ist auf alle Fälle schnell genug, man wird aber 
wahrscheinlich einen speziellen Kernel-Treiber brauchen, der die Info 
'Break Condition bei Byte X' an eben jenes Byte bindet.

[Ingo F. (ingof)]

Danny B. schrieb:
> man wird aber wahrscheinlich einen speziellen Kernel-Treiber brauchen, der
> die Info 'Break Condition bei Byte X' an eben jenes Byte bindet.

Kerneltreiber schreibt man nicht mal so eben....

Break abfragen selber ist zumindest möglich
BRKINT in c_iflag:
http://man7.org/linux/man-pages/man3/termios.3.html

Was meinst du mit
> Du wolltest das ja aus dem Userspace machen,

[Ferdinand S. (sir_bacon)]

Hallo Danny Und Ingo,

Vielen Dank für die schnelle Antworten und Diskussion! Hat mir wirklich 
geholfen. Also wenn ich es richtig verstanden habe ist dann folgende 
Situation vorhanden.

1. Hardware
Ein direkte Verknüpfung geht ja Hardwaremäßig, aber nicht vom Software. 
Grund ist dafür das der Collector schon ein fertiges DatenFrame erwartet 
und um dass zu machen muß der SW die der Serielle Schnittstelle lest ein 
Break erkennen.

1a. Hardware Lösung
Um es jetzt doch aus zu werten muß ich mit also ein AVR-NET-IO bei 
Pollin besorgen, inklusive einen ATmega644P-20PU und Netzteil. Mit der 
Vorhanden Hex-Datei wird dies dann Funktionieren.
Anbindung ist wie folgt:
TX vom Adapter an Pin 1 vom NetIO
RX vom Adapter an Pin 2 vom NetIO
5V vom Adapter an Pin 10 vom NetIO
Allerdings wird ich dann nicht der 3 LED's haben

1b. Software Lösung
Wenn ich es richtig verstehe vom 
https://www.raspberrypi.org/documentation/configuration/uart.md mus der 
PL011 eigentlich schon ein Break Erkennung machen. Nur der Frage ist wie 
man es dann richtig umsetzt für Benutzung in Collector. Oder?

Habe mir heute einiges angesehen wie WiringPi oder PySerial, und vielen 
Fragen im Internet. Habe aber noch keine schöne Lösung gefunden.

In der wiki steht ein Option "# SERIALDEVICE="/dev/ttyUSB0", ich glaube 
deswegen habe ich mit gedacht das es mit eine 'einfache' UART/Serial-USB 
Adapter gehen wurde. Diese sollte auch Break Erkennung machen. 
Vielleicht wird ich mir dies einmal anschließen und einfach mal der Bus 
aufzeichnen, mal sehen was er dann bekommt.

2. Regler Typ
Wenn ich also nur ein Sensor habe und ein RC30 wird der wert schon auf 
der Bus engezeigt. Also brauche ich der RC35 nur um es im Wohnzimmer an 
zu sehen.

3. Anleitung
Danke, hat vile geholfen.

4. Installation
Also der RPi mit der Collector ausrüsten und dann z.B. an ein Datenbank 
auf meine Synology verweisen. Nur der Webseite soll dan auch auf der 
Synology liegen.

Danke

[Danny B. (maniac103)]

Ferdinand S. schrieb:
> 1a. Hardware Lösung
> Um es jetzt doch aus zu werten muß ich mit also ein AVR-NET-IO bei
> Pollin besorgen, inklusive einen ATmega644P-20PU und Netzteil. Mit der
> Vorhanden Hex-Datei wird dies dann Funktionieren.
> Anbindung ist wie folgt:
> TX vom Adapter an Pin 1 vom NetIO
> RX vom Adapter an Pin 2 vom NetIO
> 5V vom Adapter an Pin 10 vom NetIO
> Allerdings wird ich dann nicht der 3 LED's haben

Geht - zumindest wenn du nicht senden/steuern, sondern nur lesen willst 
- auch deutlich einfacher ;-) Siehe den Schaltplan hier: 
Beitrag "Re: EMS > Adapter > NetIO > Raspi" ... das ist ein 
EMS-zu-UART-Adapter, der ein Protokoll auswirft, das direkt mit dem 
Collector kompatibel ist. Teilekosten vielleicht 5€; du brauchst halt 
noch einen Atmega-Programmer (für das NetIO allerdings auch).

> Wenn ich es richtig verstehe vom
> https://www.raspberrypi.org/documentation/configuration/uart.md mus der
> PL011 eigentlich schon ein Break Erkennung machen. Nur der Frage ist wie
> man es dann richtig umsetzt für Benutzung in Collector. Oder?
>
> Habe mir heute einiges angesehen wie WiringPi oder PySerial, und vielen
> Fragen im Internet. Habe aber noch keine schöne Lösung gefunden.

Eine schöne Lösung wird's dafür nicht geben ... das Problem ist recht 
speziell :-/

[Ingo F. (ingof)]

Habe mal zum spielen einen PIC mit zwei Seriellen Ports im DIP-Gehäuse 
mit 14 Beinchen bestellt. Wegen internen Oszillator würden keine 
externen Bauteile benötigt (Außer EMS-Teil natürlich)

Meine Idee wäre dass er einfach eine Umsetzung vom EMS-Bus auf die 
serielle Schnittstelle macht. Also ein kleiner ems-Gateway ohne 
Ballast(Ethernet,CAN,USB-Serial und den Rest).
Ohne SMD und daher auch viel einfacher nachbaubar.

Also als kleines Interface dass an den RASPI angeschlossen werden könnte 
und das Framing für den collectord besitzt.

könnte bei auch mit einem USB-TTL-Serial am PC oder NAS angeschlossen 
werden.

Hätte jemand an soetwas Interesse?

[Ferdinand S. (sir_bacon)]

Hallo Ingo,

Na klar, das wird mich sicherlich interessieren! Ich möchte ja nur der 
EMS-Bus auswerten, also alles andere an der AVR-NET-IO wurde nicht 
benutzt.

Wenn diese Adapter der EMS-Telegramme direkt auf der gute Framing für 
der Collector bereiten kann wäre das Super.

Wenn ich darf einige Fragen dazu:
* Können Sie sagen welches Modell Sie gekauft haben? (Reine Interesse)
* Ist es angedacht nur zum Lesen oder auch Senden?
* Wenn es mit ein USB-TTL-Serial kommuniziert könnte Mann ggf. auch auf 
ein RPi dies so anschließen und dann z.B. mit Python auslesen. Oder habe 
ich das falsch?

[Ingo F. (ingof)]

Ferdinand S. schrieb:
> welches Modell
PIC16F15325-I/P

Über die serielle Schnittstelle kann dann über EMS-collector oder auch 
andere Programme gesteuert werden. Weil der PIC dann den EMS-Bus steuert 
und nur die Nachrichten über den Bus gehen. Aber dann alles über die 
Serielle Schnittstelle:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-gw-netio

Kommt erst in zwei Wochen. Wollte den Quelltext vom EMS-Gateway und den 
Bootloader verwenden und anpassen.

Kann aber keine Termine nennen und nichts versprechen...

[StephanW (Gast)]

Moin zusammen.
Ich bin über den 2107 thread hier angekommen. Bei dem habe ich das erste 
Jahr gelesen - sehr interessant! - und den Rest sowie den hier 
überflogen. Ist ja echt ne Menge Stoff!

Habe eine Buderus gb125 mit rc300 und würde gerne nur die Daten lesen 
und loggen. Nun habe ich zwar einen Rpi daheim, und könnte auch löten, 
habe aber leider von der theoretischen (Elektrik, Elektronik, 
Programmierung ) Seite eigentlich keine Ahnung. Interessierter Laie was 
das angeht, auch wenn ich im Prinzip verstehe was ihr macht.

Gibt es mittlerweile eine Lösung, wo man vielleicht nur noch Hardware 
basteln und dann aber fertige Software Pakete / skripte etc installieren 
kann um die Daten zu loggen?

Gruß Stephan

[Ingof (Gast)]

StephanW schrieb:
> Gibt es mittlerweile eine Lösung, wo man vielleicht nur noch Hardware
> basteln und dann aber fertige Software Pakete / skripte etc installieren
> kann um die Daten zu loggen?


Das ist Ansichtssache. Plug&Play gibt es nicht.

Die *Hardware* besteht aus bis zu Drei Teilen.
1) EMS-Bus Interface für Ethernet
2) Hardware für CollectorD
3) Evtl. weitere Hardware für Webinterface/Datenbank/openHAB

Für den EMS-Bus gibt es iegentlich zwei Hardwaretypen:
*) NetIO-Board mit selbstgebauter/gekaufter Adapterplatine (und 
Prozessoraustausch für zweiter Serial-Port)
*) EMS-Gateway (Fertig aufgebaut wenn wieder verfügbar, 
Sammelbestellung)

Die *Software*
Auf einem RaspberryPi könnte dann folgende Software laufen:
1) collectord um die Verbindung mit netIO oder EMS-Gateway herzustellen
2) mySQL-Server
3) php_Webinterface

oder auch:
1) collectord um die Verbindung mit netIO oder EMS-Gateway herzustellen 
und MQTT
2) MQTT
3) openHab

oder auch irgendwas anderes.

Das erste Softwarepaket hatte ich mal auf dem Raspberry Pi laufen.
Ein paar weiter Infos hast Du dazu bestimmt schon im Wiki gesehen..
https://emswiki.thefischer.net/

Der NetIO und die Adapterplatine kann mit etwas bastelerfahrung selber 
zusammenbauen.
Beim EMS-Gateway ist das wegen viel SMD nicht möglich.

Ich überlege eine kleine Platine nur für den Serial-Port zu bauen die 
auch an den Raspberry Pi angeschlossen werden könnte und einfacher 
nachbauen zu ist.

[Ingof (Gast)]

Hoffe Danny muss jetzt nicht viel korrigieren ;-)

[Ingo F. (ingof)]

Ingof schrieb:
>> .....dann aber fertige Software Pakete / skripte etc installieren
> ...Plug&Play gibt es nicht.

Das wichtigste vergessen:
Dazu muss der collectord compiliert werden und die Andere Software 
installiert und alles konfiguriert werden.

Aber mit etwas nachlesen probieren sollte das möglich sein.
Bei Problemen einfach hier oder in einem der anderen Thread 
nachfragen...

[StephanW (Gast)]

Hallo,

danke für die übersichtliche Darstellung.
Wie gesagt, Hardware basteln ist nicht so das Problem, ich habe aktuell 
auch ziemlich viele Elektronik Entwickler als Kollegen mit 
entsprechender Hardware. :)
Auch Software nach Anleitung installieren und ggf. mit Hilfe anpassen - 
ok, denke schon.
Allerdings kann ich wie gesagt nicht programmieren und komme nicht aus 
der E-Ecke.
Deswegen kann ich auch die Hard- und Software Varianten in ihren Vor- 
und Nachteilen bzw. ihrer Eignung nicht beurteilen und bin auf eure 
Empfehlung angewiesen.
Letztendlich möchte ich einfach den zeitlichen Verlauf der Daten loggen, 
archivieren, und grafisch darstellen können (manuelle Wahl des 
Zeitfensters, ggf. mehrere zum Vergleichen).

Gruß

[Jens H. (Gast)]

Moin zusammen,

ich weiß meine Logindaten gerade nicht (bin im Büro), mir gehen aber 
gerade ein paar Dinge durch den Kopf die ich lieber jetzt gleich frage, 
bevor ich die heute Abend vergessen habe ;-)

a)
Ich habe die alte Platine im Einsatz(daher ist die Abfrage direkt über 
Lan und/oder JSON nich möglich), die per USB an einem Pi2 hängt, den 
Collector incl. mysql DB und auch die php Weboberfläche ebenfalls.
Aus aktuellem Anlass (Update anderer Pi auf Stretch) überlege ich den 
Umzug auf einen Pi3 und auf Stretch.

Würde das eigentlich funktionieren und falls ja, wie wäre die beste 
Vorgehensweise ?


b)
Für meine Hausautomatisation hatte ich geplant regelmäßig die aktuellen 
Datensätze aus der DB abzufragen um nicht ständig die Daten aus der 
Schnittstelle umzusetzen. Das funktioniert auch relativ gut, bis auf die 
Daten aus der letzten Tabelle, da bricht die Abfrage nach 3min mit 
Timeout ab. Ich könnte natürlich die Scriptlaufzeit hoch setzen, denke 
aber das ich einfach nur eine ungünstige Abfrage genutzt habe.
Das ganze läuft auf PHP, vielleicht hat ja jemand eine performantere 
Lösung ;-)
Alternativ müsste man vielleicht nur die DB regelmäßig aufräumen um 
nicht den ganzen alten Ballast zu durchsuchen, da ich dafür zumindest 
nur die aktuellsten Daten benötige.
Irgendwelche Vorschläge ?

$sq3="SELECT b.sensor, c.name, b.value, c.unit, b.starttime, b.id from $mysql_Tbl_name2 b, $mysql_Tbl_name3 c where c.type=b.sensor and ((select max(id) from $mysql_tbl_name2 where sensor =c.type)=b.id)";

Gruß
Jens

[Kreka K. (Firma: keine) (kreka)]

Der Link zum Wiki unter dem Punkt

Doku zum Telegrammaufbau:
- Wiki
  http://ems-gateway.myds.me/dokuwiki/

hat sich geändert zu:

- Wiki
  https://emswiki.thefischer.net/

[maikelmaikel (Gast)]

Hier noch eine interessante Faktensammlung zum Busprotokoll:

https://domoticproject.com/ems-bus-buderus-nefit-boiler/

Stammt vom 10.04.2018

[AlexStreit (Gast)]

Ich habe einen GB125 Brennwertkessel und ein EMS-Board von BBQ_KEES 
welches ich an einen RasPi angeschlossen habe. Die Adapterschaltung ist 
direkt mit dem rückwärtigen EMS-Bus der Heizung verbunden (nicht über 
Diagnoseklinke)

Ich empfange eine Menge Daten, die aber irgendwie nicht zu den 
EMS-Telegrammen passen. Hier gab es schonmal ein Posting mit dem GB125 
aber dort sahen die Daten noch ganz anders aus.

Die Ausgabe kommt aus dem ems-collector:

Sind das gültige Daten oder empfange ich Müll?

O: Got bytes 0x89 00
IO: Got bytes 0x9 00
IO: Got bytes 0x90 00 0x10 00 0x89 00
IO: Got bytes 0x9 00
IO: Got bytes 0x93 00
IO: Got bytes 0x89 00 0x9 00 0x94 00
IO: Got bytes 0x90 00 0x10 00 0x89 00
IO: Got bytes 0x9 00 0x95 00
IO: Got bytes 0x89 00
IO: Got bytes 0x9 00 0x90 00 0x10 00 0x96 00
IO: Got bytes 0x89 00
IO: Got bytes 0x9 00 0x90 00 0x10 00
IO: Got bytes 0x89 00 0x9 00 0x97 00
IO: Got bytes 0x89 00
IO: Got bytes 0x9 00 0x9a 00
IO: Got bytes 0x90 00 0x10 00 0x89 00
IO: Got bytes 0x9 00
IO: Got bytes 0x8 00 0x18 00 0x52 0x2 0x8c 0x64
IO: Got bytes 0x64 0xa 0x10 0x15 0x1 0x2 0x26 0x7d
IO: Got bytes 00 0x80 00 0x2 0x13 0xff 0x3d 0x48
IO: Got bytes 00 00 0xff 0x1 0x10 0x83 00 0x66
IO: Got bytes 00
IO: Got bytes 0x8
IO: Got bytes 00 0x18 0x1b 00 00 00 00 00
IO: Got bytes 00 00 0x50 00 00 0x8a 00
IO: Got bytes 0xa2 00
IO: Got bytes 0x89 00
IO: Got bytes 0x9 00 0x90 00 0x10 00
IO: Got bytes 0xaa 00
IO: Got bytes 0x89 00
IO: Got bytes 0x9 00
IO: Got bytes 0x90 00 0x10 00 0x89 00
IO: Got bytes 0x9 00 0xb2 00
IO: Got bytes 0x89 00 0x9 00 0xba 00
IO: Got bytes 0x90 00 0x10 00 0x89 00
IO: Got bytes 0x9 00 0xc2 00
IO: Got bytes 0x89 00
IO: Got bytes 0x9 00
IO: Got bytes 0x90 00 0x10 00
IO: Got bytes 0xca 00

[ingof (Gast)]

Habe mir das noch mal genauer angesehen.

Deine Verwendete Platine wandelt vermutlich nur Den EMS-Bus auf die 
Serielle Schnittstelle um und machst sonst nichts. Kein Ausfiltern des 
Pollings oder Umwandeln des EMS-Framings (0x00 mit Stopbit 0)

Der EMS-collector erwartet wohl ein Framing mit 0xAA 0x55 <Länge>

Es müsste also so aussehen:
Beitrag "Re: Faktensammlung Buderus EMS"

Kann mir dann auch nicht vorstellen dass ein Schreiben auf den EMS-Bus 
möglich ist. Vermutlich nur lesen.

[ingof (Gast)]

Ups... hier der richtige Link:
Beitrag "Re: Faktensammlung Buderus EMS"

[NoFis (Gast)]

Dieses Projekt hat mir geholfen, meine Buderus GB162/RC35 über mqtt in 
Homeassistant anzubinden: https://github.com/proddy/EMS-ESP.
Im Debug-Modus kann man sich die Daten auch über die ser. 
Schnittstelle/USB ausgeben lassen.

[AlexStreit (Gast)]

Vielen Dank für das Feedback. Ich hatte, bevor ich den RasPi an das 
Adapterboard angeschlossen hatte, einen Wemos D1 Mini mit der ems-esp 
Firmware angeschlossen.

Leider kamen dort nie irgendwelche Daten von der Adapterplatine an; ich 
ging davon aus, daß der Wemos irgendwie kaputt war. Jetzt habe ich mir 
einen Wemos D1 besorgt und die ems-esp-Firmware geflasht. Hier habe ich 
jetzt den Effekt, daß ich wenn serial=on ist gar keine Meldungen 
empfange.

Wenn ich serial=off setze, bekomme ich alle 20sek die folgende Meldung 
"Error! Unable to read from EMS bus. Retrying in 20 seconds..."

Wenn ich serial=on setze sind die Fehlermeldungen weg ich bekomme aber 
keine Daten. Hat jemand eine Idee?

[The M. (therealme)]

Gibt es mittlerweile Fortschritte bei der Dekodierung der 
EMSplus-Telegramme?
Ich habe meine Erkenntnisse mal hier niedergeschrieben:

https://github.com/Th3M3/buderus_ems-wiki

[AlexStreit (Gast)]

Hallo @TheM,

benutzt Du einen RasPi um die Telegramme zu dekodieren? Ich habe mir die 
Telegramme auch angesehen, weiss aber nicht, wie ich diese "schneiden" 
soll. Zu sagen, daß nach jedem "00" ein neues Telegramm anfängt ist mE 
falsch. Falls Du eine Routine zur Telegrammerkennung hast würde ich mir 
diese mal sehr gerne ansehen.

Gruß,
Alex

[ingof (Gast)]

Also generell werden Telegramme (Polling und die Antworten) mit einem 
Break beendet. Habe noch mal die Seite ganz wenig überarbeitet:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme

Es kann gerne jeder mithelfen die Telegramme zu ergänzen.
Einfach mailen. Die Registrierungsfunktion hatte ich wegen SPAM 
abgeschaltet.

[ingof (Gast)]

Ich kann bei der "Decodierung" der Telegramme leider nicht weiter 
helfen. Meine Heizung hat "nur" den EMS-Bus und kein EMS+.

[AlexS (Gast)]

Hallo zusammen,

bin gerade am überlegen, wie ich Telegramme erkennen kann. Ich habe 
einen Raspi und einen ESP8266.

1) Der RasPi hat keine Break-Erkennung an seinem "mini" UART
2) Mit dem esp kenne ich mich noch zu wenig aus um da was basteln zu 
können
3) USB-UART mit Break Erkennung wäre eine Idee; ich weiss aber nicht, 
wie ich das in einem "Standard" C-Programm abfragen kann.

Alternativ könnte ich einen Stream-Parser bauen, der nach jedem 0x00 
versucht, ein gültiges Telegramm zu erkennen. Das sollte ja durch den 
bekannten Aufbau und die Prüfsumme kein Problem sein.

Wie ist denn Euer Setup beim Telegramm-Parsen? Hat jemand einen Raspi im 
Einsatz und könnte ein bisschen Code zur Verfügung stellen?

[AlexS (Gast)]

Ich habe einen GB125 30kw Ölbrenner mit RC35 und MC10 und
habe jetzt mal einen hexdump an meinem RasPI mit 9600 8n1 gezogen:

hexdump -C /dev/ttyAMA0

00000000  90 10 89 09 e0 89 09 90  10 e8 89 09 90 10 89 09 
|....�....�......|
00000010  8a 89 09 8b 90 10 89 09  8c 89 09 90 10 8d 89 09 
|................|
00000020  90 10 89 09 8e 89 09 8f  90 10 89 09 91 89 09 90 
|................|
00000030  10 92 89 09 90 10 89 09  93 89 09 94 90 10 89 09 
|................|
00000040  95 89 09 90 10 96 89 09  90 10 89 09 97 89 09 9b 
|................|
00000050  90 10 89 09 a3 89 09 90  10 ab 89 09 90 10 89 09 
|....�....�......|
00000060  b3 89 09 bb 90 10 89 09  c3 89 09 90 10 cb 89 09 
|�..�....�....�..|
00000070  90 10 89 09 d3 89 09 db  90 10 89 09 e3 89 09 90 
|....�..�....�...|
00000080  10 eb 89 09 90 10 89 09  8a 89 09 8b 90 10 89 09 
|.�..............|
00000090  8c 89 09 90 10 8d 89 09  90 10 89 09 8e 89 09 8f 
|................|
000000a0  90 10 89 09 91 89 09 90  10 92 89 09 90 10 89 09 
|................|
000000b0  93 89 09 94 90 10 89 09  95 89 09 90 10 96 89 09 
|................|
000000c0  90 10 89 09 97 89 09 9a  90 10 89 09 a2 89 09 90 
|............�...|
000000d0  10 aa 89 09 90 10 89 09  b2 89 09 ba 90 10 89 09 
|.�......�..�....|
000000e0  c2 89 09 90 10 ca 89 09  90 10 89 09 d2 89 09 da 
|�....�......�..�|
000000f0  90 10 89 09 e2 89 09 90  10 ea 89 09 90 10 89 09 
|....�....�......|
00000100  8a 89 09 8b 90 10 89 09  8c 89 09 90 10 8d 89 09 
|................|
00000110  90 10 89 09 8e 89 09 8f  90 10 89 09 91 89 09 90 
|................|
00000120  10 92 89 09 90 10 89 09  93 89 09 94 90 10 89 09 
|................|
00000130  95 89 09 90 10 96 89 09  90 10 89 09 97 89 09 99 
|................|
00000140  90 10 89 09 a1 89 09 90  10 a9 89 09 90 10 89 09 
|....�....�......|
00000150  b1 89 09 b9 90 10 89 09  c1 89 09 90 10 c9 89 09 
|�..�....�....�..|
00000160  90 10 89 09 d1 89 09 d9  90 10 89 09 e1 89 09 90 
|....�..�....�...|
00000170  10 e9 89 09 90 10 89 09  8a 89 09 8b 90 10 89 09 
|.�..............|
00000180  8c 89 09 90 10 8d 89 09  90 10 89 09 8e 89 09 8f 
|................|
00000190  90 10 89 09 91 89 09 90  10 92 89 09 90 10 89 09 
|................|
000001a0  93 89 09 94 90 10 89 09  95 89 09 90 10 96 89 09 
|................|
000001b0  90 10 89 09 97 89 09 9c  90 10 89 09 a4 89 09 90 
|............�...|
000001c0  10 ac 89 09 90 10 89 09  b4 89 09 bc 90 10 89 09 
|.�......�..�....|
000001d0  c4 89 09 90 10 cc 89 09  90 10 89 09 d4 89 09 dc 
|�....�......�..�|
000001e0  90 10 89 09 e4 89 09 90  10 ec 89 09 90 10 89 09 
|....�....�......|
000001f0  8a 89 09 8b 90 10 89 09  8c 89 09 90 10 8d 89 09 
|................|
00000200  90 10 89 09 8e 89 09 8f  90 10 89 09 91 89 09 90 
|................|
00000210  10 08 1a 00 25 64 64 00  e1 01 10 92 89 09 90 10 
|....%dd.�.......|
00000220  89 09 93 89 09 94 90 10  89 09 95 89 09 90 10 96 
|................|
00000230  89 09 90 10 89 09 97 89  09 98 90 10 89 09 a0 89 
|..............�.|
00000240  09 90 10 a8 89 09 90 10  89 09 b0 89 09 b8 90 10 
|...�......�..�..|
00000250  89 09 c0 89 09 90 10 c8  89 09 90 10 89 09 d0 89 
|..�....�......�.|
00000260  09 d8 90 10 89 09 e0 89  09 90 10 e8 89 09 90 10 
|.�....�....�....|
00000270  89 09 8a 89 09 8b 90 10  89 09 8c 89 09 90 10 8d 
|................|
00000280  89 09 90 10 89 09 8e 89  09 8f 90 10 89 09 91 89 
|................|


Ich sehe viele wiederkehrende Muster aber nichts passt auf die 
angegebenen Telegramme.

[ingof (Gast)]

AlexS schrieb:
> 00000210  10 08 1a 00 25 64 64 00  e1 01 10 92

[ingof (Gast)]

AlexS schrieb:
> 000000d0  10 aa 89 09 90 10 89 09  b2 89 09 ba

[ingof (Gast)]

00d0 ist doch keins...

[AlexS (Gast)]

ingof schrieb:
> AlexS schrieb:
>> 00000210  10 08 1a 00 25 64 64 00  e1 01 10 92


00210 ist auch keins. Das Problem fängt bei 1a an...

[Ingof (Gast)]

1A ist das Offset der Daten.

[AlexS (Gast)]

Hmmm. Müsste das dann nicht:

0x10 0x08 0xFF 0x1a

heissen? Bzw. fehlt da nicht der Offset?

[Ingof (Gast)]

Auf dem EMS+ Bus werden die EMS und EMS+ Telegramme gesendet.
Also doch folgende Werte möglich für das dritte Byte, oder?

EMS ohne Offset 00x0
EMS mit Offset  0x1A
EMS+ 0xFF

[AlexS (Gast)]

Stimmt, Du hast vollkommen recht; ich hab mich fälschlicherweise voll 
auf EMS+ konzentriert. Die Heizung schickt aber anscheinend nur 
EMS-Telegramme. (mittlerweile habe ich sogar verstanden, wie ich die 
EMS-Bus-Tabellen interpretieren muss). Ausserdem habe ich mehr über das 
Problem mit meinen Daten herausgefunden. Es gibt jemanden, der auf dem 
RasPi bereits einen Protokollparser geschrieben hat. Als ich diesen auf 
die Daten losgelassen habe, kam folgendes raus: (Auszug)

UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
 Daten:  08 00 18 00 0b 02 ce 64 00 00 00 00 00 02 60 7d 00 80 00 00 00 
ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler

UBAMonitorWWMessage ( 08 00 34 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25
 Daten:  08 00 34 00 3c 02 60 7d 00 21 00 00 03 00 06 a4 8d 00 b4 57 d3 
00 97 00 89 - CRC-Fehler

UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
 Daten:  08 00 18 00 0b 02 ce 64 00 00 00 00 00 02 60 7d 00 80 00 00 00 
ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler


UBAMonitorWWMessage ( 08 00 34 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25
 Daten:  08 00 34 00 3c 02 60 7d 00 21 00 00 03 00 06 a4 8d 00 b4 57 d3 
00 95 00 89 - CRC-Fehler

UBASollwerte ( 10 08 1a 00)
         01 02 03 04 05 06 07 08 09
 Daten:  10 08 1a 00 00 00 00 00 91 - CRC-Fehler

RCTimeMessage ( 10 00 06 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17
 Daten:  10 00 06 00 13 05 16 1e 19 10 03 01 0c 00 10 00 ed - CRC-Fehler

UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
 Daten:  08 00 18 00 0b 02 ce 64 00 00 00 00 00 02 60 7d 00 80 00 00 00 
ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler

UBAMonitorWWMessage ( 08 00 34 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25
 Daten:  08 00 34 00 3c 02 60 7d 00 21 00 00 03 00 06 a4 8d 00 b4 57 d3 
00 91 00 89 - CRC-Fehler


-> Irgendwie scheinen die CRC-Daten fehlerhaft zu sein. Allerdings sehe 
ich daß verschiedene Telegramme (z.B. UBA Monitor fast) identisch sind. 
Wenn es wirklich Störungen auf der Leitung wären, würde ich erwarten 
,daß die Telegramme leicht unterschiedlich wären.

Ich habe als Beispiel die Zeit-Telegramme rausgepickt:

RCTimeMessage ( 10 00 06 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17
 Daten:  10 00 06 00 13 05 16 1e 19 10 03 01 0c 00 10 00 ed - CRC-Fehler

Jahr=0x13 (2019)
Monat=0x05 Mai
Stunden=0x16 22
Tage=0x1e 30
Minuten=0x19 25
Sekunden=0x10 16
Wochentag=0x03 Donnerstag
Flags 0x01 -> Sommerzeit

CRC=0x0C

Die Daten klingen alle plausibel (sind frisch gezogen). Leider weiss ich 
nicht, wie die CRC berechnet werden soll. Eine CRC-8 wäre 0x47

[AlexS (Gast)]

Ich habe mich selbst nochmal mit meinen falschen CRC's beschäftigt.


-> Bei der Heizung wird immer derselbe CRC ausgegeben, obwohl sich der 
Inhalt geändert hat CRC ist immer 0x83

Wenn ich mir die Rohdaten ansehe empfange ich auch wirklich immer genau 
die falsche CRC.

Kennt jemand das Phänomen? Kann das mit dem Break und dem RasPi-Uart 
zusammenhängen? Andererseits, hat derjenige, von dem ich das Skript 
'geliehen' habe keine Probleme. Er verwendet auch den Raspi-Uart


UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
crc_ist0x83 crc_soll0xaa
 Daten:  08 00 18 00 27 02 a4 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 
ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler
data published


UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
crc_ist0x83 crc_soll0x85
 Daten:  08 00 18 00 27 02 a3 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 
ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler
data published


UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
crc_ist0x83 crc_soll0x85
 Daten:  08 00 18 00 27 02 a3 64 00 01 01 20 00 02 52 7d 00 80 00 00 00 
ff 30 59 00 00 ff 00 00 83 00 - CRC-Fehler
data published

[ingof (Gast)]

Was sind denn die "Rohdaten"? Kommen die auch vom Raspi?

Habe die Erfahrung gemacht dass sich die serielle Schnittstelle unter 
Linux nicht so gut mit RAW-Daten verträgt.
Die Schnittstelle muss erst durch die Konfiguration(Posix) dazu 
gezwungen werden die wirklich ankommenden Daten unverfälscht weiter zu 
geben.
Einige Zeichen (XON, XOFF, Zeilenumbrüche, ....) werden gerne 
umgewandelt oder unterdrückt.

Vielleicht enthält Dein Datensatz zufällig eines dieser Zeichen die bei 
der Heizung vom Programmierer nicht aufgetreten sind.

Sind Deine Telegramme denn richtig aufgebaut und ergeben Sinn? Oder sind 
dort irgendwelche Werte "verrutscht"?


Die CRC Berechnung hat mich damals fast in den Wahnsinn getrieben. Rudi 
hatte damals die 0x12 "gefunden".
Hier der Links zum ersten Code zur CRC-Berechnung:
Beitrag "Re: Logamatic 2107 Schnittstelle"

[ingof (Gast)]

Habe die CRC-Berechnung noch mal schnell ins Wiki gepackt:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme#crc

[AlexS (Gast)]

ingof schrieb:
> Was sind denn die "Rohdaten"? Kommen die auch vom Raspi?
>

Die Rohdaten habe ich mit
(stty raw; cat > /srv/received.log) < /dev/ttyAMA0
gesammelt

Bytes fehlen bei den Telegrammen nicht; bis jetzt habe ich keine 
"Ausreisser" gefunden (ausser der CRC natürlich...)

Hier ist die dekodierte Meldung mit der falschen CRC

UBAMonitorFast ( 08 00 18 00)
         01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31
crc_ist0x83 crc_soll0x0a
 Daten:  08 00 18 00 0b 02 af 64 00 00 00 00 00 02 48 7d 00 80 00 00 00 
ff 30 48 00 00 ff 00 00 83 00 - CRC-Fehler
data published

Die Rohdaten sehen so aus (ist ein anderes Telegramm mit einer anderen 
WW-Temperatur):
000001d0  xx xx xx xx xx xx xx xx  xx xx xx xx 08 00 18 00 
|................|
000001e0  0b 02 b0 64 00 00 00 00  00 02 48 7d 00 80 00 00 
|..�d......H}....|
000001f0  00 ff 30 48 00 00 ff 00  00 83 00 0c 00 08 00 18 
|.�0H..�.........|




> Habe die Erfahrung gemacht dass sich die serielle Schnittstelle unter
> Linux nicht so gut mit RAW-Daten verträgt.
> Die Schnittstelle muss erst durch die Konfiguration(Posix) dazu
> gezwungen werden die wirklich ankommenden Daten unverfälscht weiter zu
> geben.
> Einige Zeichen (XON, XOFF, Zeilenumbrüche, ....) werden gerne
> umgewandelt oder unterdrückt.
>
> Vielleicht enthält Dein Datensatz zufällig eines dieser Zeichen die bei
> der Heizung vom Programmierer nicht aufgetreten sind.
>
> Sind Deine Telegramme denn richtig aufgebaut und ergeben Sinn? Oder sind
> dort irgendwelche Werte "verrutscht"?

Verrutscht oder fehlen tut nix. Es ist alles Da. Das einzige was ich 
merkwürdig finde ist daß die Vorlauf-Solltemperatur mit 11 Grad (statt 
70 gesendet wird) Die Vorlauf-Ist-Temperatur ist ok.


> Die CRC Berechnung hat mich damals fast in den Wahnsinn getrieben. Rudi
> hatte damals die 0x12 "gefunden".
> Hier der Links zum ersten Code zur CRC-Berechnung:
> Beitrag "Re: Logamatic 2107 Schnittstelle"

Ich schau mir mal die Berechnung an, Vielen Dank für Deine Hilfe!!

[Alexander Kabza (Gast)]

Hallo AlexS,

derjenige, von dem du den Code "geliehen" hast, bin ich.
Siehe http://www.kabza.de/MyHome/EMSbus.html

Funktioniert das Auslesen von deinem EMS-Bus inzwischen ohne CRC-Fehler?

LG,

      Alex

[Ingo F. (ingof)]

Alexander Kabza schrieb:

> derjenige, von dem du den Code "geliehen" hast, bin ich.
> Siehe http://www.kabza.de/MyHome/EMSbus.html


Hallo Alex,

Wie klappt das denn mit der Break-Erkennung auf dem Raspi?
Ist es möglich die Zeichen schnell genug jedes einzelne Byte auszulesen 
um den Frameerror auszuwerten?
Oder wie erkennst Du das Ende der Polling(Telegramme)?

Gruß
Ingo

Edit:
gerade auf Deiner Seite gefunden:

Unregelmäßig dazwischen kommen Zeichenfolgen mit zwei Byte, wobei das zweite Byte immer 0x00 ist. Das erste Byte scheint ein Zähler zu sein, ...

das ist das Polling mit dem die Busteilnehmer angesprochen werden. Es 
werden im größeren Abstand die Adressen hochgezählt... Das macht der 
Busmaster wohl zwischendurch wenn er Langeweile hat.
Sobald ein Busteilnehmer darauf antwortet und sich dadurch am Bus 
"anmeldet" wird er haufiger abgefragt. Also Busadresse mit MSB gesetzt.

[Alexander Kabza (Gast)]

Hallo Ingo,

erst einmal danke für deinen Beitrag von 2011, nach dem ich meinen 
Pegelwandler in erster Version aufgebaut habe.

Ich verstehe die beiden Fragen nicht ganz, versuch aber doch mal meine 
Antwort auf die erste Frage uu geben: Mein Python-Script liest so lange 
von der seriellen Schnittstelle, bis die ersten vier Bytes eines 
bekannten EMS-Header kommen. Ist das der Fall, dann wird die darauf 
folgende Botschaft eingelesen. Jede Botschaft hat ja eine festgelegte 
Länge. Ich muss also gar nicht auf ein Break oder Ende warten.

Die Frage mit dem Frameerror verstehe ich aber nun wirklich nicht. Ich 
prüfe mit der Prüfsumme, ob die Botschaften fehlerfrei angekommen sind. 
Und nur dann wird das jeweilige XML-File erstellt.

Funktioniert auf diese Weise seit August 2017 sehr zufriedenstellend.

Danke auch für die Info mit dem Polling. Ich werde das wenn OK für dich 
auf meiner Homepage entsprechend anpassen.

LG,
    Alex

[Ingo F. (ingof)]

OK, das habe ich vermutet.

Das Ende der Telegramme wird durch ein Break gekennzeichnet.
Also ein 0-Byte mit Stopbit 0. Das ist ein FrameError.
Diesen FrameError können nicht alle seriellen Schnittstellen auswerten.
Wenn die Schnittstelle das unterstützt muss allerdings jedes Zeichen 
einzeln ausgelesen werden. Wenn mann 5 Zeichen aus dem Buffer ausliest 
kann man nicht feststellen welches Byte dieses falsche Stop-Bit-0 hatte.

Du liest einfach alle Daten ein bis z.b. 08 00 06 für die Uhrzeit 
auftaucht und wertest die folgenden Daten aus.

Edit:
Die Telegrammlänge andert sich ja an der selben Anlage nicht. Aber an 
einer anderen Anlage können die längen von Deiner abweichen.

Gruß
Ingo

[Alex S. (Gast)]

Hallo Alex K,

habe gerade erst Deine Antwort gesehen.
Ich verwende die Break-Erkennung auf dem Raspi nicht;  hatte mich 
kurzzeitig damit beschäftigt, es dann aber aufgegeben. Laut 
Hardwarebeschreibung sollte der "echte" UART am RPi3 ja eine 
BRK-Erkennung haben, die ist aber nie angeschlagen.

Ich habe immer noch dieselben "sonderbaren" CRC's.
Mittlerweile vermute ich, daß das nichterkannte Break das CRC-Byte 
negativ beeinflusst.
Interessanterweise habe ich bis jetzt kein einziges Telegramm mit 
unplausiblen Daten gesehen (also z.B. Bitkipper). Nur die CRC's sind 
alle nachweislich kaputt (aber immer die gleichen "falschen" Werte).

Ich habe Dein Skript angepasst, daß es mir die Heizungsdaten an einen 
MQTT-Server postet, die ich dann in OpenHAB weiterverwerte. Wenn Du 
möchtest, kann ich es Dir zukommen lassen.

Gruß,

Alex S.

[Ingof (Gast)]

Hallo Alex

dass nicht erkannte BRKs die CRC verändern halte ich für 
unwahrscheinlich.

Sicher dass der Serialport richtig auf RAW konfiguriert ist?

Könnte sein dass in den CRC Steuerzeichen sind durch den Serial Port 
verändert werden. Z.B. LF, CR, XON, XOFF, ....

Aber das hatte ich bestimmt schon erwähnt....

[Ingof (Gast)]

Machmal werden diese Teichen ersetzt, manchmal unterdrückt.

[Alex S. (Gast)]

Hallo Ingo,

ich hatte versucht, die Ausgabe mit 'stty -F /dev/serial0 raw' auf raw 
umszustellen. Alle Zeichen (bis auf die CRC und das BRK kommen korrekt 
aus dem Treiber raus, deshalb glaube ich nicht, daß es daran liegt.

Ich hatte mir bei bbqkees einen Wemos D1 mini mit EMS Adapter bestellt; 
der hat die Telegramme, die er empfangen hatte alle als ungültig 
verworfen; allerdings kann es sein, daß ich in meiner grenzenlosen 
"Genialität" was beim Anschließen kaputt gemacht hatte....

Ich habe mir jetzt das neue "Super Deluxe EMS Wemos Adapter inkl. 
Spannungsversorgung und Klinkenkabel" für Doofe bestellt. Das soll am 
Montag kommen; ich bin gespannt, ob es die EMS-Telegramme richtig 
erkennt. Hier kann ich beim Anschluss schonmal nix falschmachen... 
Irgendwie bin ich sowieso der einzige, der dieses merkwürdige 
CRC-Problem hat.

Gruß,

Alex

[Ingof (Gast)]

Alex S. schrieb:
> ... hatte versucht, die Ausgabe mit 'stty -F /dev/serial0 raw' auf raw
> umszustellen.

Habe ein eigenes Programm für einen anderen Bus geschrieben. Dort hatte 
es zumindest nicht gereicht...

[Alex S. (Gast)]

Hallo Ingo, Hallo Alex,

habe jetzt den Ersatz-esp bekommen, angeschlossen und er erkennt alle 
Telegramme ohne irgendwelche CRC-Probleme... (Interessanterweise hatte 
der erste bestellte esp8266 mit EMSBus-Adapter garkeine korrekten 
Telegramme erkannt, es waren Daten da, die wurden aber alle verworfen) 
Ich interpretiere das ganze jetzt so, daß der erste von mir bestellte 
esp8266 irgendwelche Probleme hatte und ich anschliessend die ganze Zeit 
dem RPi-Serial-TTY-Subsystem so richtig auf den Leim gegangen bin. ich 
werd noch zum Elch... Ingo, Du hattest vollkommen Recht!!

Der erste esp8266 wurde über USB von einem externen Netzteil und nicht 
vom ems-Bus selbst gespeist, gibt es bekannte Probleme bei der 
getrennten Spannungsversorgung? (EMS-Adapter vs. esp8266/RPi)

Liebe Grüße und frohes neues Jahr,

Alex

[Alexander S. (Firma: CreaValix GmbH) (tantalus)]

Hallo zusammen,
nachdem ich irgendwann den EMS-Bus an meiner Heizung entdeckt habe und 
diesen mit dem Home Assistant steuern wollte, habe ich diesen bald an 
meinem RPi gehabt.

In den letzten Wochen ist dann ein vollständiger Protokollstack 
entstanden, den ich hier kurz vorstellen möchte, vor allem, weil der 
Buszugriff (polling, breaks, ...) in C unter Linux geschrieben ist, weil 
es hier Fragen gab.
Dieser Teil liest und schreibt die Pakete über eine Posix Message Queue.

Der höhere Teil ist eine Python-Bibliothek. Diese versteht die ganzen 
Nachrichten, kennt die Feldtypen (Boolean, Integer, String) und die 
Einzeiten (Temperatur, Datum, ...). Werte können so ganz einfach auch 
gesetzt werden.

Das ganze Zeug findet sich unter

https://github.com/CreaValix/ems_bus

[Dieter (Gast)]

Das finde ich einen sehr guten Beitrag den Du dort veröffentlicht hast. 
Da steckt eine Menge an Arbeitszeit von Dir drin. Hoffe das würdigen die 
das auch Nutzen entsprechend.

[regn (Gast)]

Hallo Alexander

Du schreibst:
Currently only EMS v1 is supported
d.h. für den EMS plus ist es gar nicht zu gebrauchen?
Buderus verwendet nun ja schon über 10 Jahre den Plus.

reicht als Verbindungs-Hardware  das bbqkees EMS interface board für
€32,95  ?
und das dann mit einem Pi verbinden?
welcher würde mindestens gebraucht?

[maniac103 (Gast)]

regn schrieb:
> .h. für den EMS plus ist es gar nicht zu gebrauchen? Buderus verwendet
> nun ja schon über 10 Jahre den Plus.

Das Problem ist einfach, dass sich noch nie jemand mit einer 
EMS-Plus-Heizung hingesetzt hat, um die Inhalte der Plus-Telegramme zu 
dekodieren. Unterstützung dafür in die Software einzubauen wäre kein 
großes Problem, aber es wird keiner seine Heizung austauschen, um diese 
Arbeit zu machen - zumindest ich für meinen Teil habe nicht vor, das zu 
tun ;-)

[Ingo F. (ingof)]

regn schrieb:
> und das dann mit einem Pi verbinden?
> welcher würde mindestens gebraucht?

maniac103 schrieb:
> Das Problem ist einfach, dass sich noch nie jemand mit einer
> EMS-Plus-Heizung hingesetzt hat

maniac103 schrieb:
> zumindest ich für meinen Teil habe nicht vor, das zu
> tun ;-)

Hallo regn

Das könnte soviel bedeuten wie:

"Das Board kaufen, mit der Heizung verbinden und versuchen die 
Telegramme zu entschlüsseln."

Was anderes ist beim EMS+ Bus bisher nicht möglich.
Wünsche mir dass meine Heizung (kein EMS+) noch ein paar Jahrzehnte 
hält.

Sobald weitere Telegramme entschlüsselt sind wird Maniac103 die bestimmt 
in den collectorD einbauen.

Wenn die Platine für EMS funktioniert wird sie auch für EMS+ 
funktionieren.
Es ändern sich nur die Daten im Telegramm und etwas der Telegrammaufbau.

[Robert R. (regn)]

Hallo, Ingo F

von Dir ist doch das
https://emswiki.thefischer.net/doku.php?id=wiki:ems:telegramme ?
im Wesentlichen stimmt das alles für EMS+ , außer die 
Ansauglufttemperatur - da kommt nur stark schwankender Unsinn.
Ich habe das Monitoring nun mit einem Pi und dem script auf
http://www.kabza.de/MyHome/EMSBus/EMSbus.php
am Laufen.
Grüße

[Ingo F. (ingof)]

Robert R. schrieb:
> ...im Wesentlichen stimmt das alles für EMS+ , außer die
> Ansauglufttemperatur - da kommt nur stark schwankender Unsinn.

Ja, soweit müsste das "Abwärtskompatibel" sein.
Bei der Ansaugluft kommt bei mir auch nichts brauchbares. Aber meine 
Anlage hat auch keinen Sensor dafür.

Bei EMS+ gibt es aber noch weitere Telegramme die bei mir nicht 
aufgeführt sind. Das ist dann aber wohl ein anderes Format.

Einige Vermutungen meinerseits:
https://emswiki.thefischer.net/doku.php?id=wiki:ems:plus-telegramme

Falls Du dort weiteres "gefunden" hast dann gerne noch mal posten oder 
direkt im Wiki eintragen.

[Daniel G. (daniel_g427)]

Hallo zusammen,

ich hab in dem alten Post Beitrag "Logamatic 2107 Schnittstelle" 
noch ein wenig angehängt, bevor ich auf diesen hier gestoßen bin. Ich 
habe mir mittlerweile einen Adapter gebaut, der ein ESP32-WROOM-32D 
integriert und damit die Logamatic ins WLAN bringt. Aktuell bin ich 
dabei, eine ESPhome Komponente zu erstellen, die dann die Heizung auch 
in den Home Assistant bringt.

Ich habe einen ganzen Satz unbestückter Platinen hier, für die sich auch 
schon ein paar Interessenten gemeldet haben. Noch sind nicht alle weg...

Wer genaueres nachlesen möchte, hier mein Blog-Post dazu:
https://the78mole.de/reverse-engineering-the-buderus-km217/

Viel Spaß :-)

[JoeClots (Gast)]

Приветствую!

Недорогой монтаж видонаблюдения в Одессе  D-Link,  MikroTik,  Commax
 видеонаблюдение ардуино в Одессе
 охранная система квартиры

https://securitycam.com.ua/?add_to_wishlist=6123


 видеонаблюдение из телефона в Одессе
 охранная система норд

[Michal K. (gashtaan)]

Hi guys, sorry for the english, I don't speak german. I'd like to know 
what MCU is used in Buderus RC35 regulator... anyone knows?

[Michal K. (gashtaan)]

In case if anyone is still interested in this topic, I'm writing some 
documentation about Buderus RC35 internals.
https://github.com/gashtaan/buderus-rc35-internals

[Robert R. (regn)]

Yes, I  am. still monitoring Buderus

[F. F. (pic18f)]

Hallo, gibt es eine Möglichkeit beim RC30 die Uhr zu stellen, der 
Telegrammtyp 0x06 scheint nur zum Lesen geeignet zu sein. Bei meiner 
Bedieneinheit ist der Inkrementalgeber defekt und ich kann hier nichts 
mehr eingeben. Ich möchte die Uhr auch mit der NTP - Zeit 
synchronisieren.
Viele Grüße
Franz

[Michal K. (gashtaan)]

I don't know how it is in RC30, but for RC35 the time is writable and I 
guess both units should work the same. What telegram data are you 
sending to set the time?

[F. F. (pic18f)]

Kann man den RC35 wirklich stellen? Ich überlege mir diesen zu kaufen.
Den RC30 kann man offensichtlich nicht stellen. (Zeit)

Siehe Beitrag "Re: Faktensammlung Buderus EMS"
Ich habe es über Telnet versucht:
Telnet:
0b 10 06 00 ...

[Robert R. (regn)]

Telnet ?? wie ist denn der RC35 mit einem Netzwerk verbunden?