Forum: Haus & Smart Home EMS > Adapter > NetIO > Raspi


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Habe mal mein Log angehangen...

Irgendwas läuft da richtig schief.

IO: Sending bytes 0x90 0x3f 00 0x54
IO: Got bytes 0xaa 0x55 0x20
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3f 00 0x54 0xf0

Auf das gesendete Telegramm mit der Abfrage von 84 Bytes aus Telegramm 
kommt also
- eine Antwort mit Länge 32, aber ohne Daten
- eine Antwort, die nach einer Kopie des Sendepuffers aussieht

Konsequenterweise versucht es der Collector daraufhin noch ein paar mal, 
aber bekommt weiterhin keine sinnvolle Antwort.

Mal zum Vergleich, so sieht es bei mir aus:

IO: Sending bytes 0x90 0x3f 00 0x54
IO: Got bytes 0xaa 0x55 0x1f 0x10 0xb 0x3f 00 0x1 0x1b 00 0x2d 0x1 0x54 
00 0x8a 0x21 0x1b 0x20 0x2d 0x21 0x54 0x20 0x8a 0x41 0x1b 0x40 0x2d 0x41 
0x54 0x40 0x8a 0x61 0x1b 0x60 0xd6

Da musst du wohl nochmal in die Gateway-Sourcen schauen ;-)
IO: Sending bytes 0x90 0x3f 0x1b 0x39

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> - eine Antwort mit Länge 32, aber ohne Daten
> - eine Antwort, die nach einer Kopie des Sendepuffers aussieht

Na dann kann es ja nicht wirklich funktionieren...

Werde mich mal durch die Sourcen durchkämpfen...

von Niffko _. (niffko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

dass RC30/35 bei Abfrage größerer Telegramme in die Knie gehen ist wohl 
normal ... das Thema hatten wir -glaube ich- auch schon mal. Der 
Service-Key fragt zumindest die entsprechenden Telegramme auch in 
kleineren Chunks ab.

Ich hab mich kürzlich zum ersten mal mit der Abfrage solcher 
"Überlängen" beschäftigt. Dabei ist mir etwas aufgefallen, was evtl. 
etwas mit Ingos Problem zu tun haben könnte.

Fragt man mehr Datenbytes an, als der RC30/35 liefern kann, wird keine 
CRC auf den Bus geechot (siehe Anhang). Kann das jemand verifizieren? 
Würde man jetzt das letzte Byte für einen CRC-Check hernehmen, geht das 
natürlich schief.

Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge 
der abzufragenden Datenchunks von vorn herein auf einen Wert 
festzulegen, der auch sicher geliefert werden kann.



//Niffko

von Ingo F. (ingof)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Niffko _ schrieb:
> Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge
> der abzufragenden Datenchunks von vorn herein auf einen Wert
> festzulegen, der auch sicher geliefert werden kann.
Die CRC werden im collector ja nicht mehr ausgewertet und deswegen 
vermutlich erst mal egal.
Denke dass mit der 00-CRC bei "Überlängen" ist ein spezielles Problem 
vom NetIO. Auf dem EMS-Bus werden tzrotzdem CRC gesendet.

Mit dem EMS-Gateway ist es zumindest nicht so.
Denke aber es wäre keine schlechte Idee dass auf eine Datenlänge von 
0x1b zu begrenzen. Mehr Daten werden sowieso nicht geliefert.

Kann das mit der CRC mit dem EMS-Gateway nicht nachvollziehen...

Vermute mal das Problem vom EMS-Gateway könnte sich dann nicht mehr so 
auswirken. Nur die Telegramme die ein größeres Offset als 0x1b haben 
könnten das Problem sein. Kleinere Telegramme gehen ja wohl, so wie es 
aussieht, Problemlos durch.

Bin aber natürlich bei der Fehlersuche im EMS-Gateway dabei..

: Bearbeitet durch User
von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _ schrieb:
> Fragt man mehr Datenbytes an, als der RC30/35 liefern kann, wird keine
> CRC auf den Bus geechot (siehe Anhang). Kann das jemand verifizieren?
> Würde man jetzt das letzte Byte für einen CRC-Check hernehmen, geht das
> natürlich schief.

Ich kann das zwar nicht direkt verifizieren, da der Collector die CRC 
nicht sieht und ich am NetIO grade kein RS232 angeschlossen habe. 
Allerdings schließe ich daraus, dass
- auf 0x90 0x3d 00 0x2a eine Antwort kommt und
- gleichzeitig die Anzahl an Paketen mit CRC-Fehlern im NetIO gleich 
bleibt (d.h. kein neuer CRC-Fehler auftritt) und
- mein ethersex-Code in der Tat das letzte Byte als CRC interpretiert

dass ich das Problem nicht sehe. Das ist allerdings noch mit der RC30, 
mit der RC35 habe ich es noch nicht probiert.

BTW, ein paar CRC-Fehler scheinen normal zu sein. Ich habe grad mal in 
die EMS-Statistik des NetIO geschaut, und der sagt 32326006 korrekte 
Pakete zu
114743 mit CRC-Fehlern, also eine Fehlerrate von ~0.4% kaputten Paketen. 
Ich bin mir allerdings nicht ganz sicher, wie das passieren kann...
(Anderer Fun Fact am Rande: nur 15% der übertragenen Daten sind wirklich 
Pakete mit Nutzdaten, der Rest ist Polling ohne Datenübertragung.) Auch 
noch interessant: mehr als 6000x waren die aufgelaufenen Daten > 64 
Byte, was, soweit ich meinen Code noch überblicke, heißt, dass manchmal 
doch längere Pakete auf dem Bus sind. Das muss ich nochmal mit einem 
größeren Puffer verifizieren)

Ingo F. schrieb:
> Niffko _ schrieb:
>> Sollte dies tatsächlich so sein, wäre es vermutlich clever, die Länge
>> der abzufragenden Datenchunks von vorn herein auf einen Wert
>> festzulegen, der auch sicher geliefert werden kann.
> Die CRC werden im collector ja nicht mehr ausgewertet und deswegen
> vermutlich erst mal egal.

Es wäre vermutlich nicht egal, wenn der Collector keine Antwort bekäme, 
was bei falscher CRC passieren würde ;-)

> Denke dass mit der 00-CRC bei "Überlängen" ist ein spezielles Problem
> vom NetIO. Auf dem EMS-Bus werden tzrotzdem CRC gesendet.

???
Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau 
siehst du ein NetIO-Problem?

> Vermute mal das Problem vom EMS-Gateway könnte sich dann nicht mehr so
> auswirken. Nur die Telegramme die ein größeres Offset als 0x1b haben
> könnten das Problem sein. Kleinere Telegramme gehen ja wohl, so wie es
> aussieht, Problemlos durch.

Es gibt schon noch andere Telegramme, die in deinem Log komisch 
aussehen. Z.B. dieses:

IO: Sending bytes 0x90 0x37 00 0xc
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x37 00 0xc 0xa0

Bei der Wiederholung hat es funktioniert:

IO: Sending bytes 0x90 0x37 00 0xc
IO: Got bytes 0xaa 0x55 0xf 0x10 0xb 0x37 00 0xff 00 0x2 0x2 00 0x1 0x1 
00 0x3c 0xff 0x58 0x48

oder hier (erste Antwort kaputt, zweite ok):

IO: Sending bytes 0x90 0xa5 00 0x19
IO: Sending bytes 0x90 0x3f 0x54 0x1
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3f 0x54 0x1 0xf1
IO: Got bytes 0xaa 0x55 0x6 0x10 0xb 0x3f 0x54 00 0x15 0x65

oder hier

IO: Sending bytes 0x88 0x34 00 0xc
IO: Got bytes 0xaa 0x55 0x5 0xb 0x88 0x34 00 0xc 0xbb

oder hier (beide kaputt)

IO: Sending bytes 0x90 0x37 00 0xc
IO: Sending bytes 0x90 0xa5 00 0x19
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x37 00 0xc 0xa0
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0xa5 00 0x19 0x27


IMHO existiert da ein systematisches Problem ;-)

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Es wäre vermutlich nicht egal, wenn der Collector keine Antwort bekäme,
> was bei falscher CRC passieren würde ;-)

Hatte Niffkos Screenshot so verstanden dass der NetIO nur in diesem Fall 
Telegramme ohne CRC rausschickt. Der collector würde dann das Telegramm 
trotzdem mit fehlernder CRC bekommen. Aber der collector ignoriert diese 
CRC.

Habe ich das falsch verstanden?

Danny Baumann schrieb:
> Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau
> siehst du ein NetIO-Problem?

in seinem Screenshots waren bei den Abfragen mit Längen über 0x1b am 
Ende immer eine 0x00. Ist das nicht die fehlende CRC? Ist das ein 
Datenbayte?

Da bei mir max 0x1b Datenbytes übermittelt werden habe ich angenommen 
dass es kein Datenbyte sein kann.

Danny Baumann schrieb:
> IMHO existiert da ein systematisches Problem ;-)

Das wollte ich damit nicht ausschließen. Das ist eine Tatsache dass der 
EMS-Gateway sich nicht korrekt verhält.

Nur funktionieren bei mir die Telegramm mit weniger als 0x1b Daten. Auch 
wenn sie ab und zu ein zweites mal angefragt werden müssen.

Wollte also nicht irgendjemandem die Schuld geben.
Würde vernutlich dann bedeuten dass es bei mir dann vermutlich laufen 
würde wenn nur 0x1b Daten angefragt werden.

Habe da so eine Vermutung gehabt was das Problem beim EMS-Gateway 
verursachen könnte. Aber das war vermutlich ein Irtum.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Hatte Niffkos Screenshot so verstanden dass der NetIO nur in diesem Fall
> Telegramme ohne CRC rausschickt. Der collector würde dann das Telegramm
> trotzdem mit fehlernder CRC bekommen. Aber der collector ignoriert diese
> CRC.
>
> Habe ich das falsch verstanden?

Niffko's Screenshot bezieht sich auf die Antwort, die (in seinem Fall) 
von der RC30 kommt, nicht darauf, was seine Sendehardware (IIRC 
verwendet er kein NetIO) rausschickt.
Und nochmal ;-) Der Collector sieht nie irgendeine CRC. Entweder die 
empfangende Hardware (z.B. NetIO) sieht die CRC als OK an und schickt 
die Daten an den Collector weiter, oder sie schickt die Daten nicht 
weiter und der Collector sieht gar nix.

> Danny Baumann schrieb:
>> Ich kann dir nicht folgen. Welche '00-CRC' meinst du, und wo genau
>> siehst du ein NetIO-Problem?
>
> in seinem Screenshots waren bei den Abfragen mit Längen über 0x1b am
> Ende immer eine 0x00. Ist das nicht die fehlende CRC? Ist das ein
> Datenbayte?

Ja, das ist ein Datenbyte. Niffko wollte darauf hinaus, dass bei Länge 
25 (0x19) die CRC noch da ist, aber ab Länge 26 (0x1a) fehlt, erkennbar 
an der nicht mehr wachsenden Länge der Telegramme.

> Nur funktionieren bei mir die Telegramm mit weniger als 0x1b Daten. Auch
> wenn sie ab und zu ein zweites mal angefragt werden müssen.

Das sehe ich eben anders - genau deshalb habe ich ja ein paar Telegramme 
mit Länge < 27 rausgepickt, die auch kaputt sind. Soweit ich das 
beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas 
grundsätzliches kaputt, was ein erfolgreiches Senden - völlig unabhängig 
von der angefragten Länge - zur Glückssache macht. Ich denke, dass die 
beste Idee wäre, zuerst dieses Problem zu fixen, und dann auf eventuelle 
Probleme mit bestimmten abgefragten Längen zu schauen. IMHO besteht eine 
nicht allzukleine Wahrscheinlichkeit, dass diese sich nach der Behebung 
des generellen Problems in Luft auflösen werden.

Für das Debugging würde ich übrigens empfehlen, das Webfrontend erstmal 
komplett wegzulassen und nur die Telnet-Schnittstelle des Collectors zu 
verwenden, um die Komplexität runterzubekommen. Dann mit ein paar 
einfachen Befehlen anfangen (WW-Temperatur, Tag-/Nachtmodus, Ferienzeit 
usw.), um zu schauen, wie sich nicht fragmentierte Pakete verhalten, und 
gleichzeitig Gateway- und Collector-IO-Log beobachten. Dann beobachtete 
Inkonsistenzen fixen ;-) Wenn das geht, zu fragmentierten Paketen 
(Schaltzeitplan, 'hk1 requestdata' usw.) übergehen.

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Soweit ich das
> beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas
> grundsätzliches kaputt,

Habe doch gesagt dass das eine Tatsache ist....

Danny Baumann schrieb:
> und nur die Telnet-Schnittstelle des Collectors zu
> verwenden,

Wie bekomme ich dass denn hin?
habe das cli von Moosys ems-tools genommen.

Gibt es noch eine direkt Möglichkeit über telnet? Wenn ja, wie komme ich 
da hin? Beim Telnet auf 7777 und 7778 kommt sofort Die Verbindung wurde 
abgebrochen.

Wäre der Telnet auf die Ports OK oder liege ich da falsch? Habe noch den 
Appache laufen. Aber die Webseite vom Fronend nicht geöffnet also dürfte 
der Port doch nicht belegt sein.

Das Log vom EMS-Gateway für den collector-Port gibt es nicht wirklich 
soweit ich das sehe. Das Log über den USB-Port sieht ja anders aus. 
Müsste da wohl einen Spiegelport einrichten und wireshark nehmen.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Danny Baumann schrieb:
>> Soweit ich das
>> beurteilen kann, ist in den Gateway-Senderoutinen irgendetwas
>> grundsätzliches kaputt,
>
> Habe doch gesagt dass das eine Tatsache ist....

Ich will's dir ja auch nicht unter die Nase reiben :) Ich wollte einfach 
nur sagen, dass es sich IMHO nicht lohnt, sich auf das Längenproblem zu 
konzentrieren, wenn das wahrscheinlich nur ein Symptom eines anderen 
Problems ist.
>
> Danny Baumann schrieb:
>> und nur die Telnet-Schnittstelle des Collectors zu
>> verwenden,
>
> Wie bekomme ich dass denn hin?
> habe das cli von Moosys ems-tools genommen.
>
> Gibt es noch eine direkt Möglichkeit über telnet? Wenn ja, wie komme ich
> da hin? Beim Telnet auf 7777 und 7778 kommt sofort Die Verbindung wurde
> abgebrochen.

Genau das (Telnet auf 7777) sollte gehen {wenn entsprechend konfiguriert 
- wenn das nicht der Fall wäre, würde das Frontend aber auch nicht 
funktionieren).

> Wäre der Telnet auf die Ports OK oder liege ich da falsch? Habe noch den
> Appache laufen. Aber die Webseite vom Fronend nicht geöffnet also dürfte
> der Port doch nicht belegt sein.

Der Port akzeptiert auch mehrere gleichzeitige Verbindungen und lauscht 
auch auf Verbindungen von anderen Rechnern. Eventuell ein 
Firewall-Problem o.Ä.?

> Das Log vom EMS-Gateway für den collector-Port gibt es nicht wirklich
> soweit ich das sehe. Das Log über den USB-Port sieht ja anders aus.
> Müsste da wohl einen Spiegelport einrichten und wireshark nehmen.

Gut, das kann ich schlecht beurteilen. Das Log, was du oben gepostet 
hättest, sah nur ganz brauchbar aus.

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Ja seht ihr denn die Zeichen nicht :-)

Auszüge aus Ingos ems.log :

MESSAGE[15.03.2015 19:03:38]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x34 0x02 0x0a ...
MESSAGE[15.03.2015 19:03:39]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a
MESSAGE[15.03.2015 19:03:40]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a
MESSAGE[15.03.2015 19:03:41]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a
MESSAGE[15.03.2015 19:03:43]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x34 0x02 0x09 ...
Abfrage von 0x2A Bytes -> keine Antwort bei drei Versuchen



MESSAGE[15.03.2015 19:02:18]: source 0x08, dest 0x0b, type 0x34, offset 0, data: 0x0a 0x01 0xa7 ...
MESSAGE[15.03.2015 19:02:18]: source 0x0b, dest 0x90, type 0x37, offset 0, data: 0x0c
MESSAGE[15.03.2015 19:02:18]: source 0x10, dest 0x0b, type 0x37, offset 0, data: 0xff 0x00 0x02 0x02 0x00 ...
MESSAGE[15.03.2015 19:02:48]: source 0x08, dest 0x00, type 0x18, offset 0, data: 0x34 0x02 0x13 ...
Abfrage von 0x0C Bytes -> Antwort erfolgt



//Niffko

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _ schrieb:
> Ja seht ihr denn die Zeichen nicht :-)

Was meinst Du damit?
Dass nach der (partiellen) Sonnenfinsternis die Welt untergeht :-D

: Bearbeitet durch User
von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _ schrieb:
> Ja seht ihr denn die Zeichen nicht :-)

Ach menno, jetzt lenk den Ingo doch nicht wieder vom eigentlichen 
Problem ab ;-)

> Auszüge aus Ingos ems.log :
> [snip]

Etwas später im Log:
IO: Sending bytes 0x90 0x3d 00 0x2a 
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3d 00 0x2a 0x8c 
IO: Got bytes 0xaa 0x55 0x20 
IO: Sending bytes 0x90 0x3d 00 0x2a 
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3d 00 0x2a 0x8c 
IO: Got bytes 0xaa 0x55 0x20 
IO: Sending bytes 0x90 0x3d 00 0x2a 
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0x3d 00 0x2a 0x8c 
MESSAGE[18.03.2015 16:44:28]: source 0x0b, dest 0x90, type 0x3d, offset 0, data: 0x2a

Da wird dann auch ziemlich deutlich, warum keine weiteren 
Message-Zeilen kommen.

Bei deinem Problem halte ich bei nochmaligem drüber nachdenken auch 
einen Bug im Empfänger-Code für möglich. Zumindest ist auffällig, dass 
du nur bis 25 Byte empfangen kannst, während die RC30 bei mir und die 
RC35 bei Ingo 27 Bytes schickt [ich teste morgen auch noch mal mit der 
RC35]. Eventuell ein Puffer zu klein o.Ä.?

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> ... Bug im Empfänger-Code ... Eventuell ein Puffer zu klein o.Ä.?

Tja Danny, was soll ich sagen ... Punktlandung!

Die Diskrepanz von meinen 26 zu euren 27 Bytes ist mir nicht aufgefallen 
:(

Jedenfalls ... kaum macht man den Empfangsbuffer etwas größer, klappts
auch mit der CRC   * facepalm *


//Niffko

von Kay F. (jaykay)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe ein Heizung mit Solarmodul (SM10). Die Telegramme dazu sind ja 
schon im Wiki. Ist eine Aufnahme in den collector geplant? Wenn ja wann?

Habe mir den Sourcecode mal angesehen. Wie müssen die Werte der Tabelle 
umgesetzt werden? Wäre das als Beispiel richtig? Gibt es Regeln für die 
Werte Namen (Pumpe & Aussentemp ist ja nicht eindeutig)?
void
EmsMessage::parseSMMonitor()
{
    parseNumeric(0, 2, 10, EmsValue::SollTemp, EmsValue::None);
    parseInteger(2, 1, EmsValue::Mischersteuerung, EmsValue::None);
    parseNumeric(3, 2, 10, EmsValue::IstTemp, EmsValue::None);
    /* ??? */
    parseBool(5, 1, EmsValue::PumpeAktiv, EmsValue::None);
    parseInteger(7, 3, EmsValue::Mischersteuerung, EmsValue::None);
}

Danke und Gruß

JayKay

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Dany,

wie sollte denn die richtige Kommunikation zwischen EMS-Gateway/NetIO 
und collector aussehen?

ALso z.B.
zum zum NetIO:
90 06 00 06 (Empfänger, Typ, Offset, Anzahl)

vom NetIO:
10 0b 06 00 11 22 33 44 55 66

Gruß
Ingo

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Kay F. schrieb:
> Hallo!
>
> Ich habe ein Heizung mit Solarmodul (SM10). Die Telegramme dazu sind ja
> schon im Wiki. Ist eine Aufnahme in den collector geplant? Wenn ja wann?

Geplant ist da eigentlich nie etwas ;-) Entweder es gibt genügend 
(eindeutige) Informationen und jemand spricht mich drauf an, oder es 
schickt jemand einen Pull Request.

Für SM10 Monitor hab ich das grad mal gemacht: 
https://github.com/maniac103/ems-collector/commit/7c9166f31401c3fab257cc0a3f074c5507ff865f 
- probier mal.
Die Offsets im Wiki sehen allerdings komisch aus, so dass es nett wäre, 
wenn du mal ein Collector-Log mit Message-Debug, in dem die Nachrichten 
0x96 und 0x97 enthalten sind, hochladen könntest.

> Habe mir den Sourcecode mal angesehen. Wie müssen die Werte der Tabelle
> umgesetzt werden? Wäre das als Beispiel richtig? Gibt es Regeln für die
> Werte Namen (Pumpe & Aussentemp ist ja nicht eindeutig)?

'Type' ist die Art des Wertes, 'Subtype' eine Klassifizierung, wo der 
Wert herkommt. Es ist dabei nicht wirklich wichtig, unbedingt mit den 
existierenden Bezeichnungen auszukommen; wichtiger ist es, dass der Wert 
sinnvoll beschrieben ist. Essenziell ist allerdings, dass jede 
Kombination aus Type + Subtype eindeutig ist, da diese Kombination 
letztendlich den Sensor beschreibt.

>     parseNumeric(0, 2, 10, EmsValue::SollTemp, EmsValue::None);

Ich denke, dass ist die Außentemperatur?
(Interessant ist, dass du Offset 0 verwendest, was nicht zum Wiki passt 
- daher mein Kommentar oben)

>     parseInteger(2, 1, EmsValue::Mischersteuerung, EmsValue::None);

Das ist doch eine Pumpenmodulation, also EmsValue::IstModulation.

>     parseNumeric(3, 2, 10, EmsValue::IstTemp, EmsValue::None);

IstTemp ist richtig, ich habe dafür den Subtype 'SolarSpeicher' 
eingeführt.

>     parseBool(5, 1, EmsValue::PumpeAktiv, EmsValue::None);

Das braucht noch einen Subtype, ist aber ansonsten korrekt.

>     parseInteger(7, 3, EmsValue::Mischersteuerung, EmsValue::None);

EmsValue::Betriebszeit (zumindest laut Wiki)

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Hallo Dany,
>
> wie sollte denn die richtige Kommunikation zwischen EMS-Gateway/NetIO
> und collector aussehen?

http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio

:-)

> zum zum NetIO:
> 90 06 00 06 (Empfänger, Typ, Offset, Anzahl)

Das würde die ersten 6 Bytes des Telegramms 6 vom RC abfragen, ja.

> vom NetIO:
> 10 0b 06 00 11 22 33 44 55 66

Da fehlt 0xaa 0x55 + Länge am Anfang und XOR über die Daten am Ende.

von Kay F. (jaykay)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,

hier schon mal der Auszug für source 0x30 & type 0x97 (type 0x96 habe 
ich noch nicht im Logfile gefunden):

IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 00 0x1f 00 0x1 0xb8 0x1 0x4 0x99 0x91 00 0xa 0x6 
MESSAGE[10.03.2015 21:11:54]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x00 0x1f 0x00 0x01 0xb8 0x01 0x04 0x99 0x91 0x00 0x0a
DATA: Unhandled message received(source 0x30, type 0x97).
IO: Got bytes 0xaa 0x55 0x7 0x30 0x8 0x35 00 00 00 0xf6 0xfb 
MESSAGE[10.03.2015 21:11:54]: source 0x30, dest 0x08, type 0x35, offset 0, data: 0x00 0x00 0xf6
DATA: Unhandled message received(source 0x30, type 0x35).
IO: Got bytes 0xaa 0x55 0x6 0x10 0x8 0x35 00 0x11 0x11 0x2d 


IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 00 0x1f 00 0x1 0xb8 0x1 0x4 0x99 0x91 00 0xa 0x6 
MESSAGE[10.03.2015 21:12:54]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x00 0x1f 0x00 0x01 0xb8 0x01 0x04 0x99 0x91 0x00 0x0a
DATA: Unhandled message received(source 0x30, type 0x97).
IO: Got bytes 0xaa 0x55 0x7 0x30 0x8 0x35 00 00 00 0xf6 0xfb 
MESSAGE[10.03.2015 21:12:55]: source 0x30, dest 0x08, type 0x35, offset 0, data: 0x00 0x00 0xf6
DATA: Unhandled message received(source 0x30, type 0x35).


IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 0x2 0x34 0x5e 0x1 0xcf 0x3 0x4 0xa2 0xfb 00 0xa 0x55 
MESSAGE[22.03.2015 17:08:21]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x02 0x34 0x5e 0x01 0xcf 0x03 0x04 0xa2 0xfb 0x00 0x0a
DATA: Istwert Modulation = 94 %
DATA: Solarspeicher-Isttemperatur = 46.3 °C
DATA: Solar-Pumpe = AN
DATA: Solar-Betriebszeit = 303867 min



Im Display der RC35 steht:

Kollektor 48 Grad
Speicher mitte 46 Grad
Speicher unten 46 Grad
Solar-Pumpe 0%
Betriebsstunden 5064h 38 min

IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 0x1 0xe1 00 0x1 0xce 0x1 0x4 0xa3 0x6 00 0xa 0x22
MESSAGE[22.03.2015 17:24:27]: source 0x30, dest 0x00, type 0x97, offset 0, data: 0x00 0x00 0x01 0xe1 0x00 0x01 0xce 0x01 0x04 0xa3 0x06 0x00 0x0a
DATA: Istwert Modulation = 0 %
DATA: Solarspeicher-Isttemperatur = 46.2 °C
DATA: Solar-Pumpe = AUS
DATA: Solar-Betriebszeit = 303878 min

Mir ist nur nicht ganz klar warum die Message teilweise Unhandled ist.

Gruß JayKay

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Kay F. schrieb:
> Im Display der RC35 steht:
>
> Kollektor 48 Grad
> Speicher mitte 46 Grad
> Speicher unten 46 Grad
> Solar-Pumpe 0%
> Betriebsstunden 5064h 38 min
>
>
>
> IO: Got bytes 0xaa 0x55 0x11 0x30 00 0x97 00 00 00 0x1 0xe1 00 0x1 0xce 
> 0x1 0x4 0xa3 0x6 00 0xa 0x22
> MESSAGE[22.03.2015 17:24:27]: source 0x30, dest 0x00, type 0x97, offset 
> 0, data: 0x00 0x00 0x01 0xe1 0x00 0x01 0xce 0x01 0x04 0xa3 0x06 0x00 
> 0x0a
> DATA: Istwert Modulation = 0 %
> DATA: Solarspeicher-Isttemperatur = 46.2 °C
> DATA: Solar-Pumpe = AUS
> DATA: Solar-Betriebszeit = 303878 min
> 

Sieht doch schon mal gut aus. Die Kollektortemperatur steht an Offset 2, 
die baue ich morgen noch ein. Wo die RC35 allerdings 2 
Speichertemperaturen hernimmt ist mir nicht klar.

> Mir ist nur nicht ganz klar warum die Message teilweise Unhandled ist.

Naja, Nachrichten, die kamen, bevor ich die Behandlung dieser Nachricht 
heute eingebaut habe, sind halt ... unbehandelt ;)

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Jetzt wird aber auf dem EMS-Bus erst mit Offset 0x00 abgefragt und
> bekommt 0x1b (=27) Datenbytes. Das zeite Telegramm wird aber mit Offset
> 0x1C (=28) abgefragt.
> Deshalb wird das zweite Byte des AUS-Schaltpunktes am Sonntag
> ausgelassen und daher wohl vom Frontend ignoriert.

Hallo Danny,

HURRA, ich habe den Fehler im EMS-Gateway endlich gefunden!!!

Jetzt komme ich wieder zu meinem Problem.
Das Offset der Daten wird falsch berechnet.

Denke die XOR-Prüfsumme wird als Daten angesehen und mitgezählt.

Hier mal das Beispiel der Kontaktdaten. Est kommen 21 Byte Kontaktinfo1 
und dann 15 Byte Kontaktinfo2.

Bei mir vorher gesetzt:
abcdefghijklmnopqrstu
ABCDEFGHIJKLMNOPQRSTU

Zurück wird gegeben:
abcdefghijklmnopqrstu
ABCDE`GHIJKLMNOPQRSTU

Das erste Telegramm das abgefragt wird ist dieses:
10 0b a4 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 41 42 43 44 45 46 91

die XOR-Prüfsumme 0x91 am Ende enstpricht der Position des "F" was als 
"`" (0x91) beim auslesen zurückgegeben wird.

Ich habe noch weitere Proleme. Denke die sind vermutlich auch auf diesen 
Fehler zurückzuführen. (Schaltzeit die auf dieser Stelle zwischen zwei 
Telegramme befindet)

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Bitte einmal IO- und Message-Log :)

von Ingo F. (ingof)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Bitte einmal IO- und Message-Log :)

kannste haben...

Also ich habe im Frontend die "Einstellungen" Seite geladen und den 
collector restartet.

Dann noch mal die beiden Werte gesetzte (Telegramm A4)
abcdefghijklmnopqrstu
ABCDEFGHIJKLMNOPQRSTU

und  dann noch mal die Werte abgerufen.
das F wird dann durch die Prüfsumme 0x91 ersetzt.

Gruß
Ingo

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> und  dann noch mal die Werte abgerufen.
> das F wird dann durch die Prüfsumme 0x91 ersetzt.

Die Prüfsumme ist nicht 0x91, sondern 0x48. Schau selbst:
IO: Sending bytes 0x90 0xa4 00 0x2a 
Anforderung von 42 Bytes aus Telegramm 0xa4, Offset 0
IO: Got bytes 0xaa 0x55 0x5 0xb 0x90 0xa4 00 0x2a 0x15 
Echo des gesendeten Paketes? (das gehört da nicht hin)
IO: Got bytes 0xaa 0x55 0x20 0x10 0xb 0xa4 00 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f 0x70 0x71 0x72 0x73 0x74 0x75 0x41 0x42 0x43 0x44 0x45 0x46 0x91 0x48 
Antwort mit 32 Bytes (Quelle 0x10, Ziel 0x0b, Typ 0xa4, Offset 0): 0x61, 
0x62, ..., 0x91; Prüfsumme 0x48

Du schickst also ein Byte zu viel - da wirst du doch noch mal in deinen 
Code schauen müssen ;-)

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
War so froh den Fehler gefunden zu haben dass ich erst das Log 
hochgeladen habe und erst danach angesehen habe.

Aber das eine Byte abziehen das sollte ich wohl hinbekommen ...

Habe das eine Byte zuviel auch dann genau zu der Zeit gefunden als Du 
geantwortet hast...

: Bearbeitet durch User
von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Echo des gesendeten Paketes? (das gehört da nicht hin)

Stimmt schon... aber das werde ich mir dannach ansehen.
Im Moment wird alles was auf dem EMS-Bus ankommt zum collector 
rübergeschaufelt. Das ist dann auch das Echo des selbst gesendeten 
Befehls.

Werde dann die Echos der selbst gesendeten Befehle noch mal 
herausfiltern.
Eigentlich dürfte dass kein zu großes Problem sein. Aber mal abwarten...

Aber das scheint der collector erst mal zu ignorieren.

Gruß
Ingo

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Das war der selbe Text nochmal... Habs mal gelöscht...

: Bearbeitet durch User
von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny, hast Du mal ein 0x18 und 0x19 Telegramm aus Deinem Log?

Wäre mal gut ein Telegramm so zu sehen wie es aussehen soll.

Habe das eine Byte "entfernt" jetzt sieht eigentlich alles gut aus, aber 
jetzt läuft nichts mehr..

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Danny, hast Du mal ein 0x18 und 0x19 Telegramm aus Deinem Log?
>
> Wäre mal gut ein Telegramm so zu sehen wie es aussehen soll.

Bitteschön:
IO: Got bytes 0xaa 0x55 0x1d 0x8 00 0x18 00 0x2a 0x1 0xfe 0x3a 0x29 0x9 0x1 0x25 0x60 0x80 00 0x1 0xc3 0x1 0xcf 00 0x76 0x10 0x2d 0x48 00 0xc8 0xff 0x2 00 0x21
IO: Got bytes 0xaa 0x55 0x1d 0x8 00 0x19 00 00 0x3e 0x1 0xf7 0x80 00 00 00 00 0x37 0x1 0xc7 0x4a 0x7 0xe9 0xa6 00 00 00 0x6 0xf1 0x8d 0x1 0xb4 0xb7 0xd2

> Habe das eine Byte "entfernt" jetzt sieht eigentlich alles gut aus, aber
> jetzt läuft nichts mehr..

Definiere 'nichts mehr' ;-) Auslesen wird doch schon noch gehen, oder?

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> 'nichts mehr'

Bedeutet das nichts mehr geht ;-)

Das waren aber zwei andere Fehler.
Mein provisorischer Server ist mit WLAN angebunden und hatte die 
WLAN-Verbindung verloren.

Der Collector ließ sich wie immer mit Restart neustarten und zeigt OK 
an.
Als ich dann aber mal "service ems-collector stop" abgesetzt habe hieß 
es dann "Kill: Kein laufender Service gefunden [Fail]"

Nach einem Neustart funktioniert schon fast alles.
Nur die Einstellungen werden ab 50% langsamer. Einige Telegramme haben 
jetzt wohl Probleme...

Aber die Schaltzeiten, LiveStatus, Protokoll laufen Problemlos. Werde 
erst mal das Befehls-Echo rausnehmen und mir das noch mal genauer 
ansehen.

: Bearbeitet durch User
von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
So, jetzt funktioniert fast alles.

Einfach ein Byte weglassen war nciht ganz so einfach. Musste doch mehr 
geändert werden.

Das Befehlsecho und das überflüssige Byte sind jetzt auch weg.

Wenn ich die Schaltzeiten auslese werden sie jetzt auch korrekt 
angezeigt.
Nur das schrieben klappt nicht.

Muss mir mal nächste Zeit das Log ansehen.

Moosys Frontend möchte einen Wert setzten un bekommt nur als Antwort den 
Status 01 = OK. So wie es aussieht ist der Frontend damit nicht 
zufrieden und setzt dann noch vier weitere Male den Wert.

Dann stürzt bei mir der collectord ab und ich muss den service stoppen 
und neu starten, sonst meckert das Frontend dass keine Verbindung zum 
EMS-Bus vorhanden ist. Und es läuft wieder nichts.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Moosys Frontend möchte einen Wert setzten un bekommt nur als Antwort den
> Status 01 = OK. So wie es aussieht ist der Frontend damit nicht
> zufrieden und setzt dann noch vier weitere Male den Wert.

Komisch. Welcher Wert ist das? Status 01 sollte dazu führen, dass der 
Collector 'OK' meldet, vielleicht ist da irgendwas kaputt. Schick mal 
das Log von der Stelle, dann schau ich mir das mal an.

> Dann stürzt bei mir der collectord ab und ich muss den service stoppen
> und neu starten, sonst meckert das Frontend dass keine Verbindung zum
> EMS-Bus vorhanden ist. Und es läuft wieder nichts.

Wann genau ist 'dann'? Ist der Absturz reproduzierbar? Wenn ja, Log 
bitte ;) An der Stelle sind gleich 2 Dinge komisch: der Collector sollte 
nicht abstürzen ;) und wenn er es schon tut, sollte er doch vom 
Init-System neu gestartet werden?

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> vielleicht ist da irgendwas kaputt. Schick mal
> das Log von der Stelle

Werde ich dann machen wird aber noch etwas dauern...

Danny Baumann schrieb:
> Wann genau ist 'dann'? Ist der Absturz reproduzierbar?

Habe es zwei mal ausprobiert. Zweimal sah es so aus als ob der collector 
abgestürzt ist. Frontend sagte dannach immer "FATAL: keine Verbindung 
zum EMS-Bus" (oder ähnlich).

Danny Baumann schrieb:
> und wenn er es schon tut, sollte er doch vom
> Init-System neu gestartet werden?

kenne mich damit nicht so genau aus. Dauert das länger? Hatte eigentlich 
gedacht dass der collector nach dem Rechnerstart automatisch startet. 
Muss aber immer mit service ems-collector nach dem Booten starten.

dachte durch das eintragen mit „update-rc.d ems-collector defaults“ 
würde der automatisch starten..

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
>> Wann genau ist 'dann'? Ist der Absturz reproduzierbar?
>
> Habe es zwei mal ausprobiert. Zweimal sah es so aus als ob der collector
> abgestürzt ist. Frontend sagte dannach immer "FATAL: keine Verbindung
> zum EMS-Bus" (oder ähnlich).

Was genau hast du an der Stelle gemacht?

> Danny Baumann schrieb:
>> und wenn er es schon tut, sollte er doch vom
>> Init-System neu gestartet werden?
>
> kenne mich damit nicht so genau aus. Dauert das länger? Hatte eigentlich
> gedacht dass der collector nach dem Rechnerstart automatisch startet.
> Muss aber immer mit service ems-collector nach dem Booten starten.
>
> dachte durch das eintragen mit „update-rc.d ems-collector defaults“
> würde der automatisch starten..

Ich bin mir nicht sicher. Ein service ems-collector enable wird das aber 
sicherstellen.

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Ich bin mir nicht sicher. Ein service ems-collector enable wird das aber
> sicherstellen.

enable kennt er nicht bei mir...

Habe es heute noch mal getestet und  kann sagen der Fehler ist nicht 
reproduzierbar.

Also muss dass gestern an meinem Rechner oder mit der WLAN-Anbindung 
zusammengehangen habe?! Vielleicht habe ich auch mit VI in der Logdatei 
herumgespielt als der collector in die Logdatei schreiben wollte.

Also ich habe gestern und heute im Frontend unten eine Zeit von 23:30 
auf 23:00 (ohne Enter zu drücken) geändert und oben rechts auf senden 
geklickt.

Dann wurde mehrfach 10 3F 00 01 1E gesendet und als Antwort kam immer 
die 01
Nach insgesamt etwa 10 Sekunden kommt
*Error while programming!*

In Deinem Log sah es dann etwa so aus:

MESSAGE[01.04.2015 11:33:41]: source 0x00, dest 0x00, type 0x00, offset 
0, data: 0x01
IO: Sending bytes 0x10 0x3f 00 0x1 0x1e
IO: Got bytes 0xaa 0x55 0x1 0x1 0x1


Hatt einmal aber auch die Antwort im Log vor dem absenden der Nachricht. 
Aber das wird vermutlich am Logging liegen, oder. Beim senden ist kein 
Zeitstempel dabei.

Die Bestäütigung müsste so doch richtig sein, oder?
Andere Daten kann ich schreiben.

Beim Frontend gibt es noch das Problem dass beim ändern und lesen der 
max.Vorlauftemperatur immer das Offset von 0x23 verwendet wird. Und 
nicht das Offset 0x1E aus dem Wiki. Bei meiner RC35 liegt der auch wohl 
dort.

Das scheint aber eine schreibgeschütze Stelle im Telegramm zu sein die 
immer auf 0x32=50 steht.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> In Deinem Log sah es dann etwa so aus:
>
> MESSAGE[01.04.2015 11:33:41]: source 0x00, dest 0x00, type 0x00, offset
> 0, data: 0x01
> IO: Sending bytes 0x10 0x3f 00 0x1 0x1e
> IO: Got bytes 0xaa 0x55 0x1 0x1 0x1

Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors 
;-)
Ich mache aus den ACK und NACK ein Fake-Paket, damit der Parsing-Code 
das direkt ohne Spezialfälle verabeiten kann. Das heißt, dass das 
Gateway aus dem 0x1 folgendes machen muss:

<source> 0x0b 0xff 0x01

<source> ist dabei das Ziel der letzten Schreiboperation, in deinem 
konkreten Fall also 0x10. Für 0x4 gilt das Ganze entsprechend.

Meinen Code dafür kannst du hier finden: 
https://github.com/maniac103/ethersex/blob/master/protocols/ems/ems_proto.c#L62

Ich habe das gleich mal im Wiki entsprechend dokumentiert.

> Beim Frontend gibt es noch das Problem dass beim ändern und lesen der
> max.Vorlauftemperatur immer das Offset von 0x23 verwendet wird. Und
> nicht das Offset 0x1E aus dem Wiki. Bei meiner RC35 liegt der auch wohl
> dort.

Soweit ich das sehe, sendet Moosy bei der max. Vorlauftemperatur das 
Kommando "hk1 heatflowtemperature <value>", was der Collector auf 
Telegramm 61, Datenoffset 15 mappt, was wiederum laut Wiki korrekt ist 
(im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen 
Offset 20). Wie kommst du auf die 0x23 und die 0x1e? 0x1e = 30 ist - je 
nach Zählung - entweder undefiniert oder die Betriebsart, aber auf 
keinen Fall die maximale Vorlauftemperatur.

: Bearbeitet durch User
von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors
> ;-)

Wie wird dass den beim NetIO gemacht? sendet der auch so ein 
"Pseudo-Frame"?
Sonst müsste das ja auch noch dort geändert werden.

Das heisst also dass die anderen "Schreibbefehle" funktionieren weil 
dort die Bestätigung nicht abgewartet wird?

Danny Baumann schrieb:
> 0x23 und die 0x1e? 0x1e = 30

weil dort fünf mal ein Schreibbefehl an das Offset 0x23 kommt.

das 0x1E war nur geistige Verwirrung ;-) sollte 0x0F heissen was ja die 
15 ist.

Danny Baumann schrieb:
> im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen
> Offset 20

Hatte auch schon mal überlegt dass komplett zu ändern. Meistens benötigt 
man ja auch das Datenoffset und nicht das Telegrammoffset.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Danny Baumann schrieb:
>> Aaah, alles klar. Das entspricht nicht den Erwartungen des Collectors
>> ;-)
>
> Wie wird dass den beim NetIO gemacht? sendet der auch so ein
> "Pseudo-Frame"?

Ja klar, sonst hätte ich doch den Collector nicht so gebaut :) Die 
Stelle im Code, die dieses Fake-Telegramm erzeugt, hatte ich ja schon 
verlinkt.

> Das heisst also dass die anderen "Schreibbefehle" funktionieren weil
> dort die Bestätigung nicht abgewartet wird?

Ich weiß aus dem Stegreif nicht, was Moosy da tut, aber ich vermute mal, 
dass das stimmt. 'Einteilige' Zugriffe funktionieren, mehrteilige nicht.

> Danny Baumann schrieb:
>> 0x23 und die 0x1e? 0x1e = 30
>
> weil dort fünf mal ein Schreibbefehl an das Offset 0x23 kommt.

Kann ich dafür bitte ein Log haben? Ich finde spontan keine Referenz auf 
Offset 0x23 bzw. 35 im Code.

> Danny Baumann schrieb:
>> im Wiki entspricht das auf Grund der anderen Zählung dem angegebenen
>> Offset 20
>
> Hatte auch schon mal überlegt dass komplett zu ändern. Meistens benötigt
> man ja auch das Datenoffset und nicht das Telegrammoffset.

Jup. Ich werde das mal umstellen, wenn ich mal die Zeit finde.

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
> Kann ich dafür bitte ein Log haben? Ich finde spontan keine Referenz auf
> Offset 0x23 bzw. 35 im Code.

Sicher.. Aber vor Montag/Dienstag wird sich nichts mehr tun..

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Ich finde spontan keine Referenz auf
> Offset 0x23 bzw. 35 im Code.

Moin die Herren,

0x3D->0x23 ist die maximale Vorlauftremperatur speziell für 
Fußbodenheizung (RC35 only). Ist ein anderes Heizsystem eingestellt, 
muss der bekannte Offset benutzt werden.

Schöne Ostern.


//Niffko

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _ schrieb:
> 0x3D->0x23 ist die maximale Vorlauftremperatur speziell für
> Fußbodenheizung (RC35 only). Ist ein anderes Heizsystem eingestellt,
> muss der bekannte Offset benutzt werden.

Danke für die Erinnerung. Dann ist klar dass ich das nicht sehe, weil 
ich das erst vor kurzem (noch nicht vollständig) umgestellt habe und 
Moosy vorher immer 0x23 verwendet hat. Das ist ein noch offenes TODO.

> Schöne Ostern.

Danke gleichfalls :)

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
>> Schöne Ostern.

Wünsche ich auch allen..

Danny Baumann schrieb:
> Ja klar, sonst hätte ich doch den Collector nicht so gebaut :) Die
> Stelle im Code, die dieses Fake-Telegramm erzeugt, hatte ich ja schon
> verlinkt.

Hatte das mal wieder falsch verstanden. Dachte es wäre der 
Collcetor-Code und nicht vom NetIO.

Also beim EMS-Gateway wird jetzt auch das ACK/NACK richtig zum Collcetor 
gesendet z.B.: AA 55 04 10 0B FF 01 E5

Schreiben klappt jetzt auch mit dem EMS-Gateway über Moosys Frontend.

Noch mal eine Frage zum PseudoTelegramm vom NetIO.
Werden andere NACK/ACK herausgefiltert? Oder was passiert dann?

Es könnte ja passieren dass der collector und ein anderer direkter 
EMS-Busteilnehmer an den selben Teilnehmer einen Set-Befehl sendet. Wenn 
einer mit ACK und der andere mit NACK betsätigt wird kann es ja zu 
Problemen kommen. Welches ist jetzt für den collector?

Gibt zwei Möglichkeiten: Andere Bestätigungen komplett rausfiltern oder 
alle ACK NACK die kommen mit 0x00 statt der Adresse im Pseudotelegramm 
zu setzen. Damit wäre ein unterscheiden wieder möglich.

Danny Baumann schrieb:
> Moosy vorher immer 0x23

Wo ist denn das aktuelle Frontend? dass von Moosy oder irgend ein Fork 
davon? Auf dem Master sind ja schon lange keine Aktivitäten mehr, oder 
habe ich die Übersicht bei GIT falsch interpretiert?

@Danny, würde gerne meine anderen Telegramme auch über den Collector 
laufen lassen. Wie könnte ich am besten andere Telegramme über den 
Collector abarbeiten lassen?

Also am einfachsten wäre eine Abarbeitung über eine extra 
Quellcode-Datei?
Möchte ja nicht jedesmal wenn Du was am collector änderst auch den 
ganzen Code an meinem Fork ändern.

Ein Telegramm sieht z.B. so aus:
81 11 23 45 00 08 0f 00 16 0d 42 09 15 0a

(Extended-CAN. Normales Standart-CAN = 0x80)
Sind ein paar 1Wire-Sensoren und andere Daten die ich auch in eine 
MySQL-Datenbank schieben würde.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Noch mal eine Frage zum PseudoTelegramm vom NetIO.
> Werden andere NACK/ACK herausgefiltert? Oder was passiert dann?

Die werden ignoriert.

> Es könnte ja passieren dass der collector und ein anderer direkter
> EMS-Busteilnehmer an den selben Teilnehmer einen Set-Befehl sendet. Wenn
> einer mit ACK und der andere mit NACK betsätigt wird kann es ja zu
> Problemen kommen. Welches ist jetzt für den collector?

Wenn das NETIO gerade einen Befehl abgesetzt hat (nachdem es vom Master 
dazu aufgefordert wurde), weiß es, dass das nächste ACK oder NACK das 
kommt, die Antwort auf den Befehl ist. Jemand anderes kann in diesem 
Moment nix senden (zumindest nicht, wenn er sich korrekt verhält), da er 
ja nicht 'dran' ist.

> Gibt zwei Möglichkeiten: Andere Bestätigungen komplett rausfiltern oder
> alle ACK NACK die kommen mit 0x00 statt der Adresse im Pseudotelegramm
> zu setzen. Damit wäre ein unterscheiden wieder möglich.

Ja, oder die (N)ACKs denen zuordnen, die zuletzt kommuniziert haben. Ist 
aber IMHO sinnlos, da diese Antworten ohnehin uninteressant sind.

> Danny Baumann schrieb:
>> Moosy vorher immer 0x23
>
> Wo ist denn das aktuelle Frontend? dass von Moosy oder irgend ein Fork
> davon? Auf dem Master sind ja schon lange keine Aktivitäten mehr, oder
> habe ich die Übersicht bei GIT falsch interpretiert?

Ja, das von Moosy, und nein, das hast du schon richtig gesehen. Ich habe 
das Interface zwischen Collector und Frontend allerdings auch ewig nicht 
(inkompatibel) verändert, so dass diesbezüglich keine Änderungen nötig 
waren. Meine Ausführungen bzgl. 0x23 bezogen sich auf die 
Implementierung des Auslegungstemperaturkommandos im Collector.

> @Danny, würde gerne meine anderen Telegramme auch über den Collector
> laufen lassen. Wie könnte ich am besten andere Telegramme über den
> Collector abarbeiten lassen?

Mit einer neuen Message-Klasse, die im IOHandler entsprechend angelegt 
wird. Dafür braucht es natürlich ein Unterscheidungsmerkmal zu den 
EMS-Telegrammen.

> Also am einfachsten wäre eine Abarbeitung über eine extra
> Quellcode-Datei?
> Möchte ja nicht jedesmal wenn Du was am collector änderst auch den
> ganzen Code an meinem Fork ändern.

Naja, das wäre im Zweifelsfall auch kein größeres Problem. 'git merge' 
ist recht mächtig :)

> Ein Telegramm sieht z.B. so aus:
> 81 11 23 45 00 08 0f 00 16 0d 42 09 15 0a

Ich überblicke das Format zwar spontan nicht, aber ich muss es ja auch 
nicht implementieren ;)

von Martin P. (linef)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

nachdem ich das Thema NETIO und EMS schon seit Jahresanfang beobachte, 
habe ich mir nun auch eine eigene Platine mit AVR und EMS-Anschaltung 
gebaut.

Das Empfangen funktioniert nun auch schon mehrere Wochen prima, die 
Werte werden einwandfrei in fhem mithilfe des collectord 
mitprotokolliert.

Nun wollte ich mal das Senden testen und - es klappt nicht.

Ich habe in ethersex den EMS-Code mit Debugging etwas erweitert und 
gesehen, daß ca. alle 3 Sek. auf die Adresse 0x0B reagiert wird und das 
gleiche Byte auch wieder rausgeschickt wird. Auch längere Codesequenzen 
werden (zumindest vom Controller aus) verschickt.

Aber z.B. ein einfaches "getversion" läuft auf Timeout.

Nun habe ich mein Oszi rangeklemmt und etwas seltsame Kurven angezeigt 
bekommen. Meiner Meinung nach zieht der Transistor mit den Widerständen 
(4x910 Ohm) den Bus nicht weit genug runter. Ich bin bei den 
Widerständen bis auf (Gesamtwiderstand) 100 Ohm runtergegangen - kein 
Erfolg.

Siehe Bilder anbei.
Die gelbe Kurve ist am Kollektor des BC847B gemessen, die grüne Kurve 
hinter den Widerständen zu den Dioden hin (zwei Rote Kreise im Bild P0). 
Man sieht den Empfang eines Bytes und dann den Echoversuch.

Bei der Messung P1 waren 3x470 Ohm parallel geschaltet, beim Bild P2 
dann noch mehr (Gesamtwiderstand 100 Ohm), bei P3 wieder Original 2x470, 
aber mit höherem Kondensatorwert (1.5nF SMD + 2,7nf MKS 
parallelgeschaltet).

Der Bus kann doch nicht so viel Strom liefern?

Ich habe eine Logamax plus GB 172-14 mit RC300 dran.

Weiss jemand Rat?

Viele Grüße,
Martin

von Martin P. (linef)


Bewertung
0 lesenswert
nicht lesenswert
Noch ein Nachtrag.

Im Thread Beitrag "Re: Logamatic 2107 Schnittstelle" wird u.a. 
davon berichtet, daß die RC30 auf dem Bus nur mit 0,5 bis 1V sendet.
Dann würde bei mir die Hardware ja funktionieren.

Kann das jemand bestätigen, daß nur mit so geringem Spannungshub 
gesendet wird?

Viele Grüße,
Martin

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Moin Martin,

beim Senden ist der Spannungshub nicht entscheidend. Wir haben 
irgendwann mal den Konsens gefunden, dass das Senden über eine 
Stromschnittstelle läuft. Dies erklärt auch, warum der Master simultan 
empfangen und Echos auf den Bus absetzten kann. Er empfängt über 
Stromschnittstelle und echot über Spannungsschnittstelle.


//Niffko

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Martin Patzel schrieb:
> Ich habe in ethersex den EMS-Code mit Debugging etwas erweitert und
> gesehen, daß ca. alle 3 Sek. auf die Adresse 0x0B reagiert wird

Da ist schon der Fehler. Am Anfang wird nach mehreren Sekunden jede 
Busadresse abgefragt. Auch die nicht mit dem EMS-Bus verbunden sind.
Sobald ein Polling beantwortet wurde wird diese Busadresse regelmäßig 
abgefragt.

Bei mir ist es gerade fünf mal in der Sekunde (~200ms).

Was zeigt denn bei dir die RC30/35/300. Wenn das stimmt dürfte die 
Adresse 11 (0x0B) dort nicht im Busstatus auftauchen.

Entweder stimmt wirklich was nicht mit der Sendefunktion, oder Deine 
Code-Erweiterung funktioniert nicht bei jedem Polling.

Der Sendepegel beim senden ist wirklich so schwach. Das ist ganz normal. 
Wichtig ist nur dass das die gesendete PollingAntwort vom NetIO auch vom 
Bus widerholt wird. Jedes gesendete Byte von EMS-Bus-Teilnehmern wird 
vom Master sofort widerholt. Deine gesendeten Bytes sieht ohne das Echo 
nur der Busmaster (BC10/MC10?). Wenn Du den Bildausschnitt von deinem 
DOS etwas weiter nach rechts verschieben könntest solltest Du diese Echo 
auch sehen.

Ein Beispiel für die Sendefunktion ist hier zu sehen:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-telegramme

Einfach mal auf das erste Bild klicken und dann nochmals klicken um es 
in voller Größe zu sehen. Unten ist jeweils die Senderichtung (vor der 
"Sendestufe") und darüber ist das EMS-Bus-Echo. Auf Deinem DSO solltest 
Du dann noch deine "schwachen" Sendeversuche auf dem EMS-Bus sehen. 
Dieses Sendeversuche sind dort nicht zu sehen weil der Logiktester nur 
High und Low augenommen hat und keine Spannungswerte.


Habe auch mal mein kleines collector-Test-Tool in den Softwaredownload 
vom Wiki gestellt.
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:software_download

vielleicht hilft es ja ein wenig...

Gruß
Ingo

: Bearbeitet durch User
von Martin P. (linef)


Angehängte Dateien:
  • preview image for P1.jpg
    P1.jpg
    111 KB, 494 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo,

anbei nochmal ein kompletteres Bild. Sieht ähnlich aus, wie auf dem von 
Dir beschriebenen, aber nicht ganz...

Zum Coding im Ethersex nochmal: da habe ich nur Debugging dazugebaut. 
Am Ablauf mit Senden/Empfangen habe ich nichts geändert.

Auf dem Bild sieht man, daß der Master das 0x0B sendet, dann (länger als 
im Beispielbild) den Bus auf High beläßt und anschließend vermutlich ein 
Break (langes Low) sendet (gleich wie im Beispiel).
Dann sendet meine Schaltung das 0x0B. Das wird im Unterschied zum 
Beispiel nicht sofort vom Master wiederholt, sondern erst nach einer 
kurzen High-Phase des Busses. Zum Abschluß des Master-Echos sendet dann 
mein Ethersex nochmals einen kurzen Impuls - ist das überhaupt korrekt?? 
Dann ist Ruhe auf dem Bus.

In meiner RC300 sehe ich als Busteilnehmer nur die RC300 selbst und den 
Basiscontroller BC25.

Jetzt werde ich nochmal ans Debugging in Ethersex ran gehen.

Viele Grüße,
Martin

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Martin Patzel schrieb:
> Dann sendet meine Schaltung das 0x0B. Das wird im Unterschied zum
> Beispiel nicht sofort vom Master wiederholt, sondern erst nach einer
> kurzen High-Phase des Busses. Zum Abschluß des Master-Echos sendet dann
> mein Ethersex nochmals einen kurzen Impuls - ist das überhaupt korrekt??
> Dann ist Ruhe auf dem Bus.

An der Stelle, an der du den kurzen Impuls siehst, sollte ein Break 
gesendet werden. Überprüfe mal, ob du den Pin EMS_UART_TX richtig ins 
Pinning eingetragen hast.
Siehe
https://github.com/maniac103/ethersex/blob/master/pinning/hardware/netio.m4 
Zeile 89 bis 91

von Martin P. (linef)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,

ja, Pinning stimmt:

dnl
dnl port config for EMS, pin must match USART1 TX line
dnl
ifdef(`conf_EMS', `
  pin(EMS_UART_TX, PD3)
')
ifdef(`conf_STATUSLED_EMS_TX', `
  pin(STATUSLED_EMS_TX, PD4, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_OK', `
  pin(STATUSLED_EMS_RX_OK, PD5, OUTPUT)
')
ifdef(`conf_STATUSLED_EMS_RX_FAIL', `
  pin(STATUSLED_EMS_RX_FAIL, PD6, OUTPUT)
')

ansonsten würde das Senden ja wohl generell nicht funktionieren?

Viele Grüße,
Martin

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Martin Patzel schrieb:
> Hallo Danny,
>
> ja, Pinning stimmt:
>
> dnl
> dnl port config for EMS, pin must match USART1 TX line
> dnl
> ifdef(`conf_EMS', `
>   pin(EMS_UART_TX, PD3)
> ')
> ansonsten würde das Senden ja wohl generell nicht funktionieren?

Das stimmt so nicht, EMS_UART_TX wird nur und ausschließlich für die 
Break Condition verwendet. In diesem Umfeld würde ich auf alle Fälle 
debuggen. Zum Senden des Breaks wird der Transmitter ausgeschaltet, 
womit der Pin als normaler GPIO arbeitet, und der wurde bei der 
Initialisierung auf Output + Low gescchaltet

Du kannst ja spaßeshalber das ganze mal testen: usart_init() aus 
kommentieren und sicherstellen, dass ein Pullup an der TX-Leitung 
anliegt -> Ausgang sollte Dauer-Low sein. Mach das aber nicht am EMS :)

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Sendet der NetIO sooo schnell nach dem Break vom Polling?
Wäre da nicht etwas mehr Pause schöner?
Aber dass scheint den EMS-Bus ja nicht zu stören..

Auf jeden Fall liegt es am Break was da wohl kommen sollte..

von Martin P. (linef)


Bewertung
0 lesenswert
nicht lesenswert
Der Tipp mit dem Break war Gold wert!!!

Daran lags. Problem ist: Bei mir läuft der AVR mit 20 MHz. Das hat in 
der Berechnung von BIT_TIME in ems_uart.c zu einem berechneten Wert von 
260 geführt - ist natürlich zu viel für 8 Bit.
Drum war bei mir der Break dann auch so kurz.

Als Quick-und Dirty-Hack habe ich BIT_TIME halbiert und dafür den Break 
dann 22 Bit breit gemacht. Kommt zeitlich dann auf's Gleiche raus.
Und siehe da - meine Heizung redet mit mir.

Vielen Dank für die Hilfe! Echt toll, was ihr da auf die Beine gestellt 
habt!
Jetzt kann ich weiter basteln...

Viele Grüße,
Martin

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe jetzt Probleme mit Moosys Frontend.

Also EMS-Collector habe ich kompiliert und erfolgreich installiert.
Telnet auf 7777 klappt.
Moosys EMS-Tools habe ich auch erfolgreich installiert. Das 
CLI-Interface klappt auch mit dem ems-collector.

Dann habe ich Moosys webinterface/frontend installiert.
PHP läuft (mit test.php getestet) und die Webseite wird auch so weit 
angezeigt. Habe mal die Bilder der Kurven in den graphs-ordner kopiert. 
Aber die werden auch nicht angezeigt.

Alle Config-Dateien sind auch richtig angepasst.

Dummerweise findet auf dem EMS-Bus keine Kommunikation statt.

Bei der LiveANsich kommt nur der erste Balken mit 10% und bei den 
Schaltpunkten nur 90%

Hat jemand eine Idee was das Problem sein könnte???

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Was sagt denn dein Webserver-Protokoll, im Falle von Apache speziell 
error.log?

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
> Bei der LiveANsich kommt nur der erste Balken mit 10% und bei den
> Schaltpunkten nur 90%

Schau doch mal im Quelltext *.php der Seiten, was nach "progress(10);", 
bzw. "progress(90);" an Variablen aufgerufen wird.

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Was sagt denn dein Webserver-Protokoll, im Falle von Apache speziell
> error.log?

Nach meinem Log funktioniert der Zugriff nicht auf die emsincludes.
Keine Ahnung warum...

Die Dateien sind vorhanden und haben die selben Rechte und user wie auf 
dem anderen Testserver auf dem es funktioniert...
[Mon May 25 17:52:11.265865 2015] [:error] [pid 5645] [client 192.168.11.22:61985] PHP Warning:  require(/emsincludes/emssetvalue.inc): failed to open stream: Permission denied in /var/www/html/a_emslive.php on line 25, referer: http://192.168.11.33/?seite=main.php
[Mon May 25 17:52:11.265962 2015] [:error] [pid 5645] [client 192.168.11.22:61985] PHP Fatal error:  require(): Failed opening required '/emsincludes/emssetvalue.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/a_emslive.php on line 25, referer: http://192.168.11.33/?seite=main.php
[Mon May 25 17:52:13.135235 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Warning:  include(/emsincludes/emsqry.inc): failed to open stream: Permission denied in /var/www/html/a_emssched.php on line 31, referer: http://192.168.11.33/?seite=a_emslive.php
[Mon May 25 17:52:13.135325 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Warning:  include(): Failed opening '/emsincludes/emsqry.inc' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/a_emssched.php on line 31, referer: http://192.168.11.33/?seite=a_emslive.php
[Mon May 25 17:52:13.135394 2015] [:error] [pid 5644] [client 192.168.11.22:61992] PHP Fatal error:  Call to undefined function flush_buffers() in /var/www/html/a_emssched.php on line 64, referer: http://192.168.11.33/?seite=a_emslive.php
root@ems-server:/emsincludes# ls -la
insgesamt 80
drwx------ 2 user user  4096 Mai 25 17:47 .
drwx------ 7 user user  4096 Mai 24 22:11 ..
-rw-r--r-- 1 root root   248 Mai 24 21:18 config.php
-rw-r--r-- 1 root root   202 Mär  8 14:32 config.py
-rw-r--r-- 1 root root   323 Mär  8 14:34 config.pyc
-rw-r--r-- 1 root root    76 Mai 24 21:19 config.sh
-rw-r--r-- 1 root root  4682 Mär  3 19:44 emschoosers.inc
-rw-r--r-- 1 root root  4920 Mär  3 19:44 emsgetinfo.inc
-rw-r--r-- 1 root root 12859 Mär  3 19:44 emsqry.inc
-rw-r--r-- 1 root root 13281 Mär  3 19:44 emsscdesc.inc
-rw-r--r-- 1 root root  4023 Mär  3 19:44 emssetvalue.inc
-rw-r--r-- 1 root root  2469 Mär  3 19:44 emsunits.inc
root@ThinkPad-T43:/emsincludes#

Karl M. W. schrieb:
> Schau doch mal im Quelltext *.php der Seiten, was nach "progress(10);",
> bzw. "progress(90);" an Variablen aufgerufen wird.

Scheint wohl an den emsincludes zu liegen. Das ist die erste Anzeige vom 
Fortschrittsbalken.

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ingof schrieb:
> -rw-r--r-- 1 root root 12859 Mär  3 19:44 emsqry.inc

vorher waren sie auf user:user habe sie dann wie auf dem anderen Server 
auf root:root geändert. SIcherheitshalber Apache2 neugestartet.

Hat sich aber nicht geändert...

von Kay F. (jaykay)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo,

wenn ich mich nicht irre ist in Mossys Sourcen eine Datei die nur die 
PHP Short Tags verwendet <? statt <?php ...
Danach hat es bei mir geklappt.

Gruß JayKay

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kay F. schrieb:
> PHP Short Tags verwendet <? statt <?php ...

Das hatte hatte auch gedauert bis ich das herausgefunden hatte.. Habe 
ich aber schon geändert... Keine Ahnung warum er nicht auf die 
emsincludes zugreifen kann...

Die Dateien werden angezeigt und lassen sich auch mit "vi 
/emsincludes/emsqry.inc" öffnen.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Was sagt 'ls -l /’? Fehlt da evtl. das x? Ist SELinux aktiv?

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> SELinux aktiv?

Nein, jabe ich auch bisher noch nie was von gehört...
Habe Ubuntu 14.04.2 LTS Ist bei beiden auf einem Laptop installiert.
Auf Laptop wo es im Moment läuft ist es ein 64-Bit und auf dem jetztigen 
ein 32-Bit. ABer das sollte ja nichts ändern...

Ja, ist nicht ausführbar. Ist aber auf dem anderen Server auch nicht so. 
Un da funktioniert es..

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ingof schrieb:
> Ist aber auf dem anderen Server auch nicht so.

sollte heissen dass es auf beiden nicht ausführbar ist (x). Aber ist ja 
nur eine include-Datei. Die ja nicht ausgeführt werden muss, oder?

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Das Verzeichnis /emsincludes (nicht die Dateien darin) muss ausführbar 
sein, da es ansonsten nicht durchsuchbar ist.

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny Baumann schrieb:
> Das Verzeichnis /emsincludes (nicht die Dateien darin) muss ausführbar
> sein, da es ansonsten nicht durchsuchbar ist.

Stimmt, da war noch ein Unterschied. Beim neuen Server hatte das 
Verzeichnis "includes" die Rechte 700. Habe dann includes und das 
"ems-tools" Verzeichnis drüber gleich auch auf "755" gesetzt.
Habe auch Besitzer auf "root:root" geändert.

Nach Apache2 neustart hat sich aber auch nichts geändert...

Also mal eine zusammenfassung:
ls -la /:
lrwxrwxrwx 1 root root    33 Mai 25 17:51 emsincludes -> /home/user/ems/ems-tools/includes

ls -la /home/user/ems/:
drwxr-xr-x 7 root root 4096 Mai 24 22:11 ems-tools

ls -la /home/user/ems/ems-tools/:
drwxr-xr-x 2 root root  4096 Mai 25 17:47 includes

ls -la /home/user/ems/ems-tools/includes/:
insgesamt 80
drwxr-xr-x 2 root root  4096 Mai 25 17:47 .
drwx------ 7 user user  4096 Mai 24 22:11 ..
-rw-r--r-- 1 root root   248 Mai 24 21:18 config.php
-rw-r--r-- 1 root root   202 Mär  8 14:32 config.py
-rw-r--r-- 1 root root   323 Mär  8 14:34 config.pyc
-rw-r--r-- 1 root root    76 Mai 24 21:19 config.sh
-rw-r--r-- 1 root root  4682 Mär  3 19:44 emschoosers.inc
-rw-r--r-- 1 root root  4920 Mär  3 19:44 emsgetinfo.inc
-rw-r--r-- 1 root root 12859 Mär  3 19:44 emsqry.inc
-rw-r--r-- 1 root root 13281 Mär  3 19:44 emsscdesc.inc
-rw-r--r-- 1 root root  4023 Mär  3 19:44 emssetvalue.inc
-rw-r--r-- 1 root root  2469 Mär  3 19:44 emsunits.inc

Das einzige was sich sonst noch geändert hat ist jetzt das Verzeichnis.
Vorher in "/home" jetzt in "/home/user/ems/" auf dem neuen Server...

: Bearbeitet durch User
von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
OK...

Habe den Fehler gefunden.

/home/user/ems/ems-tools/ war noch auf "700" und "user:user".

Hatte das beim letzten Beitrag als letztes geändert. Hatte aber 
vergessen den Apache2 neu zu starten.

Nach einem Neustart von Apache kam "FATAL! keine Verbindung".

Dann den ems-collector neugestartet und jetzt scheint es zu laufen.

Aber warum der Ordner darüber auch diese Rechte haben muss ist mir nicht 
ganz klar.

der Ordner "user" über den "ems-tools" besitzt immer noch die Rechte 
"700" und "user:user"

bei den Graphs Ordner gab es das selbe Problem. Das x ist also bei 
Verzeichnissen nicht "ausführbar" sondern "durchsuchen erlaubt". Aber 
nur wenn das r auch gesetzt ist...

DANKE an alle

: Bearbeitet durch User
von Maarten H (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dear Ingo,


I had same type of problem after an update of my Avira antivirus SW.
When I switch off the antivirus everthing runs fine.
What I understand isthat it has to do with the ob_flush command, when I 
comment this out in emsqry.inc the a_emslive.php runs fine, even with 
Avira running, however this doesn't help for settings.

Success Maarten

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Hello Marten,

I do not know Avira. try to find the logfile and check for errors with 
the IP, Port or the collector.
I do not know whats the problem.
If there is an integrated firewall. Then try to set your Port an 
IP-address on a white list.
If not try to set the collector / webserver on a whitelist, if possible.

von Marco L. (marcol)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hat jemand eventuell noch eine unbestückte Platine über und würde diese 
verkaufen?

Gruß und Danke

Marco

von Knut S. (dk6lg)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
habe auch Interesse an einer Platine, damit der Lötigel (hat überhaupt 
keinen WAF) endlich verschwindet.

Gruß
Knut

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kann ich den Collector auch auf meinem Synology laufen lassen?
Ich habe darüber im Wiki gelesen, aber es soll noch nicht laufen?
Ich würde ungern einen Raspberry installieren...

von IngoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Meine ersten gehversuche haben noch nicht so ganz geklappt.
Auf der Synology kompilieren geht wegen dem zu alten GCC.

Es muss wohl auf einem Linux-PC kompiliert werden.

Hatte dann auch die Versuche erst mal auf Eis gelegt.

Aber vielleicht können wir ja mal einen Versuch zusammen wagen das dort 
zum laufen zu bekommen.

Auf welcher Diskstation möchtest Du es denn zum laufen bekommen?

Gruß
IngoF

von Bernd G. (bernd_g)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich nutze die Lösung nun schon lange auf meinem Pi und in bin immer noch 
allen, die sowas möglich machen, sehr dankbar!

Zur optimalen Einstellung habe ich Fragen:

Welche Werte sollte man Eurer Meinung für die Parameter auf den Bildern 
verwenden, um einen guten Kompromiss zwischen Komfort und Energiesparen 
zu erreichen?

Gruß Bernd

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
IngoF schrieb:
> Auf welcher Diskstation möchtest Du es denn zum laufen bekommen?

Hallo Ingo,
ich würde es dann auf einer synology ds215j laufen lassen wollen.
Ich muss mir aber zunächst einen Adapter bauen.
Bevor ich das in Angriff nehme wollte ich wissen ob ich unbedingt einen 
Raspberry benötige, oder es auch anders geht.

Alternativ hätte ich noch die Möglichkeit über einen 24/7 Windows PC die 
Daten abzufragen. Wie ich gelesen habe, geht dies über Telnet?


Gruß
Dennis

von IngoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sagen wir es mal so.

Es sollte machbar sein den CollectorD für die Diskstation zu 
kompilieren...

Im Moment habe ich ein altes Notebook und den CollectorD dafür 
kompiliert.
Aber das ist nur eine Notlösung und soll hinterher auf meiner 415+ 
laufen.

Notfalls ist ein RasbPi auch schnell gekauft. Die gibt es ja an jeder 
Ecke ;-)

von Benedikt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe es auf einer GoFlex Net laufen. Benoetigt eine 2,5" SATA Platte 
und ein wenig Lust am Basteln (SW) und Einlesen (z.B. 
http://doncharisma.org/2013/09/22/build-your-own-pro-nas-seagate-goflex-net-with-debian-linux-raid1-and-openmediavault/ 
). Dafuer bekommt man fuer aktuell unter 20 Euro (z.b. in der 
elektronischen Bucht) ein super NAS mit komplett freiem Linux (zum 
"Spielen" und Verwenden) - und eben eine super Plattform fuer den 
CollectorD ;-)!

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mir die Hardware auf Basis des AVR-Net-IO mit der 
Adapterelektronik für den EMS selbst zusammengebaut und die ethersex 
Software aufgespielt.
Die Elektronik funktioniert auch mit dem Testtool für Collector wenn ich 
eine Crossover-Netwerk-Verbindung zum PC habe.
Wenn ich die Elektronik aber mit einem Patchkabel an meinen Router 
stecke habe ich keine Verbindung. Nicht einmal einen Ping.

Wo könnte denn da der Fehler liegen?


Gruß
Dennis

von Martin Berger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Dennis,

hast du die Gateway IP in Net-IO vergeben?

Das Net-IO mit dem ethersex antwortet nicht auf Ping-Anfragen.

Grüße
Martin

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe es heute geschafft eine Verbindung herzustellen.
Mit dem Testtool kommen Telegramme an... :-)

Ich habe nun mal einen TCP-Client aufgemacht um zu sehen was ich direkt 
empfangen kann.
Ich kann das ganze aber noch nicht interpretieren. Gibt es dazu irgendwo 
eine Beschreibung?

Gruß
Dennis

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Hallo,
> ich habe es heute geschafft eine Verbindung herzustellen.
> Mit dem Testtool kommen Telegramme an... :-)

Von welchem Testtool sprichst due?

> Ich habe nun mal einen TCP-Client aufgemacht um zu sehen was ich direkt
> empfangen kann.
> Ich kann das ganze aber noch nicht interpretieren. Gibt es dazu irgendwo
> eine Beschreibung?

Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Von welchem Testtool sprichst due?

Testtool Collector (Testtool für die Collector-Schnitstelle vom NetIO)


Danny B. schrieb:
> Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?

Zum AVR-Net-IO auf dem Port 7950.
Es kommen Pakete an, diese sind aber deutlich länger als ich sie beim 
Testtool Collector sehe.
Aufgefallen ist mir das die Datenbytes immer durch eine 0 getrennt 
gesendet werden.
Aber wie kann ich die Pakete den Telegrammen zuordnen? (wie im Testtool 
auf der Rechten Seite)
Werden da noch Befehle an den Net-IO gesendet damit er die Telegramme 
des EMS an den Verbundenen Telnet-Teilnehmer weitergibt?

Gruß

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Danny B. schrieb:
>> Von welchem Testtool sprichst due?
>
> Testtool Collector (Testtool für die Collector-Schnitstelle vom NetIO)

Davon habe ich ehrlich gesagt noch nie gehört. Wo findet man das?

> Danny B. schrieb:
>> Wohin genau hast du dich denn verbunden? Zum NetIO? Zum Collector?
>
> Zum AVR-Net-IO auf dem Port 7950.
> Es kommen Pakete an, diese sind aber deutlich länger als ich sie beim
> Testtool Collector sehe.
> Aufgefallen ist mir das die Datenbytes immer durch eine 0 getrennt
> gesendet werden.
> Aber wie kann ich die Pakete den Telegrammen zuordnen? (wie im Testtool
> auf der Rechten Seite)
> Werden da noch Befehle an den Net-IO gesendet damit er die Telegramme
> des EMS an den Verbundenen Telnet-Teilnehmer weitergibt?

Nein. Der Ethersex-Code blubbert auf Port 7950 immer genau das heraus, 
was hier beschrieben ist: 
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio 
... 0xaa 0x55 ist dabei der Trenner zwischen den einzelnen Telegrammen.

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Davon habe ich ehrlich gesagt noch nie gehört. Wo findet man das?

Den findet man auch im EMS-Wiki.
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:software_download


Danny B. schrieb:
> Nein. Der Ethersex-Code blubbert auf Port 7950 immer genau das heraus,
> was hier beschrieben ist:
> http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-gw-netio
> ... 0xaa 0x55 ist dabei der Trenner zwischen den einzelnen Telegrammen.

Die Beschreibung hatte ich übersehen, sorry.
Dann werde ich es damit mal probieren... :-)

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Die Beschreibung hatte ich übersehen, sorry.
> Dann werde ich es damit mal probieren... :-)

Hallo,
ich kann inzwischen die Telegramme auslesen und interpretieren.
Was mir nun noch fehlt ist das geziehlte Abfragen bzw. Senden von 
Parametern.

Es scheitert glaube ich an der CRC.
Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich 
folgendes

0B 10 3F 91 01 01 <CRC>

Wie bildet man denn die CRC?
Bei einer Byteweisen XOR würde als CRC B5 herauskommen, dies scheint 
aber nicht zu funktionieren... :-(


Gruß
Dennis

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> ich kann inzwischen die Telegramme auslesen und interpretieren.
> Was mir nun noch fehlt ist das geziehlte Abfragen bzw. Senden von
> Parametern.
>
> Es scheitert glaube ich an der CRC.
> Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich
> folgendes
>
> 0B 10 3F 91 01 01 <CRC>
>
> Wie bildet man denn die CRC?
> Bei einer Byteweisen XOR würde als CRC B5 herauskommen, dies scheint
> aber nicht zu funktionieren... :-(

Benutzt du nicht Ethersex? Wenn ja, brauchst du da doch keine CRC beim 
Senden?

(Gibt es einen speziellen Grund, warum dunnicht den Collector verwenden 
willst? Der abstrahiert diese Dinge alle komplett weg...)

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Benutzt du nicht Ethersex? Wenn ja, brauchst du da doch keine CRC beim
> Senden?

Doch, ich habe die Ethersex Firmware aus dem ems-wiki.
Aber ich bekomme keinen Response auf meine Anfragen... (Auch ohne CRC, 
wie oben beschrieben)
Mache ich da noch was falsch?? :-(


Danny B. schrieb:
> (Gibt es einen speziellen Grund, warum dunnicht den Collector verwenden
> willst? Der abstrahiert diese Dinge alle komplett weg...)

Ich habe einen 24/7 PC zur Hausautomation und möchte mir nicht noch 
einen RaspberryPi installieren um den EMS abzufragen bzw. zu steuern...

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Den Collector habe ich zur Zeit nauch auf einem PC laufe

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ingof schrieb:
> Den Collector habe ich zur Zeit nauch auf einem PC laufe

Ich hatte das so verstanden das der nur auf einem Linux System läuft?
Wie installieren ich den auf einem Windows PC?

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Als Beispiel: Wenn ich die Partyfunktion setzen will, sende ich
> folgendes
>
> 0B 10 3F 91 01 01 <CRC>

ich gehe davon aus, dass du den offset (91) aus der wiki hast.

1. du must ihn in hex senden

2. der angegebene offset ist nicht nativ ems, es wird hier der header 
mitgezählt. ich weiß jetzt aber nicht, inwieweit ethersex das ausbügelt. 
um die partyfunktion für 6h zu aktivieren, muss der rc folgendes über 
den bus empfangen: 0B 10 3F 56 06 <CRC> (getestet)


// niffko

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> 1. du must ihn in hex senden

Du hast Recht, die 91 ist ja dezimal...!
Das teste ich morgen früh gleich mal!
Danke für den Anstoß... ;-)

von ingoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Ich hatte das so verstanden das der nur auf einem Linux System läuft?

Ist auch wohl so.. Habe wohl mal wieder zu schnell geschrieben und erst 
dann nachgedacht ;-)

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Ich hatte das so verstanden das der nur auf einem Linux System läuft?
> Wie installieren ich den auf einem Windows PC?

Prinzipiell sollte der Collector auch auf Windows laufen: Er hat als 
Abhängigkeiten nur Boost (gibt's auch für Windows) und mysql++ (kann man 
gegebenenfalls rauscompilieren). Ich schau mal, was ich da machen kann, 
wenn ich mal Zeit finde.

Niffko _. schrieb:
> 2. der angegebene offset ist nicht nativ ems, es wird hier der header
> mitgezählt. ich weiß jetzt aber nicht, inwieweit ethersex das ausbügelt.
> um die partyfunktion für 6h zu aktivieren, muss der rc folgendes über
> den bus empfangen: 0B 10 3F 56 06 <CRC> (getestet)

Ausgebügelt wird da nix. Ethersex fügt die Absenderadresse und die CRC 
hinzu, der Rest landet 1:1 auf dem Bus.

von Dennis (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe nun die für mich wichtigsten Werte und Steuerungsfunktionen 
zusammengesammelt.
Damit ihr auch seht warum ich soviel gefragt habe, hier ein Screenshot 
von meinem Testtool...

Werde die Daten nun in die Visualisierung der Hausautomation 
implementieren.
Vielen Dank noch einmal an alle! :-)


Gruß
Dennis

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Collector mal auf Windows compilierfähig gemacht. Mysql 
kann er in diesem Fall nicht, und er läuft nur im Vordergrund; für das 
Ausführen als Service braucht man also noch ein Extra-Tool.

Wenn es jemand probieren möchte: 
https://www.dropbox.com/s/xmdpncj8xmkmnyw/collectord.exe?dl=0

(etwa 6.3 MB groß, weil ich alles statisch linke, damit man nicht noch 
ein DLL-Package braucht)

: Bearbeitet durch User
von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mir die AVR-NET IO Platine mit dem Adapter zusammengebaut und 
an meiner GB142 getestet. Sie funktioniert! Ich kann empfangen und 
senden... :-)

Nun habe ich diese Platine an eine GB132T an den RC-Anschluss 
angeschlossen und kann auch Telegramme empfangen. Das senden geht aber 
nicht!
In den Monitorwerten (Busteilnehmer) wird mir auch nicht, wie bei der 
GB142, der Service-Key (Adresse 11) angezeigt.
Muss man das noch irgendwie aktivieren???

Gruß
Dennis

von IngoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Hallo,
> ich habe mir die AVR-NET IO Platine mit dem Adapter zusammengebaut und
> an meiner GB142 getestet. Sie funktioniert! Ich kann empfangen und
> senden... :-)
>
> Nun habe ich diese Platine an eine GB132T an den RC-Anschluss
> angeschlossen und kann auch Telegramme empfangen. Das senden geht aber
> nicht!
> In den Monitorwerten (Busteilnehmer) wird mir auch nicht, wie bei der
> GB142, der Service-Key (Adresse 11) angezeigt.
> Muss man das noch irgendwie aktivieren???
>
> Gruß
> Dennis

Das sollte genau wie an der GB142 gehen.
Wenn die Platine angeschlossen wird sollte die MC10 das mitbekommen und 
die Adresse häufiger Pollen. Dann wird auch die Platine erkannt und im 
RC angezeigt. Wenn die Dort nicht im Raumcontroller steht kann man auch 
nicht senden.

Beide haben ja den EMS-Bus. Oder ist an der GB132T eine RC300 oder RC350 
angeschlossen? Dann wäre das der EMS+-Bus

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
IngoF schrieb:
> Beide haben ja den EMS-Bus. Oder ist an der GB132T eine RC300 oder RC350
> angeschlossen? Dann wäre das der EMS+-Bus

GB132T hat EMS (und funktioniert bei mir einwandfrei)

: Bearbeitet durch User
von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> GB132T hat EMS (und funktioniert bei mir einwandfrei)

Ich hatte eine ca. 10m 3x0,75 Leitung angeschlossen. (Vielleicht war es 
auch nur 0,5mm2)
Könnte die Verbindung vielleicht nicht gut gewesen sein und ich deshalb 
nur Signale empfangen, aber nichts senden?

Gruß

von ingoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> nur Signale empfangen, aber nichts senden?

Wäre möglich...

Unterscheidet sich denn die EMS-Verkabelung bei den beiden Heizungen 
stark?
Wo ist denn die Platine angeschlossen? Direkt an der Heizung oder am 
Ende beim Raumcontroller?
Ist dort ein längeres oder anderes Kabel zur RC30/35. Eventuell dann mal 
direkt an der Heizung anschließen.

Eventuell mal an der Diagnosebuchse (Stereo Klinkenbuchse) versuchen.
Die +12V dann nicht anschließen. Ich habe gerade die STeckerbelegung ins 
Wiki gepackt:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:ems-bus

Dann müsste die Verkabelung außen vor sein?!

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Ich hatte eine ca. 10m 3x0,75 Leitung angeschlossen.

da das senden - anders als das empfangen - über eine stromschnittstelle 
realisiert ist, könnte der leitungswiderstand mglw. relevant sein ...


//niffko

von ingoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> könnte der leitungswiderstand mglw. relevant sein ...

Meine RC ist über 20 Meter 0,5mm Kabel angeschlossen und funktioniert 
problemlos. Ist aber durchaus möglich dass es daran liegt. Verdrillt 
wird das Kabel ja wohl gewesesen sein..

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> leitungswiderstand

Hallo Ihr EMS'ler,

meine beiden Leitungen, y-förmig von der Heizung abgehend, das
1. NYFAZ, 2*0.75, ca. 12 m, zur RC35
2. NYLHY, 3*0.5, zwei belegt, ca. 15 m, zum NetIO
also beide nicht verdrillt.

Alles funktioniert problemlos, dank Eurer genialen Arbeit!
Ich freue mich jeden Tag drüber!

Gruß aus der Wetterau
Karl M.

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ingoF schrieb:
> Verdrillt
> wird das Kabel ja wohl gewesesen sein..

Hallo,
verdrillt war das Kabel nicht.
An der GB142 verwende ich ein LiYCY 2 × 2 × 0,75 wovon ein Aderpaar für 
den EMS-Bus genutzt wird.
Ich werde es zunächst über ein kurzes Kabel über den Klinkenstecker 
testen und dann im 2. Step noch einmal ein anderes Kabel an der 
RC-Anschluß anschließen.
Das wird aber erst morgen etwas.
Ich werde berichten. Erst einmal danke für die Hilfe!

Gruß

von ingoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> 2. Step noch einmal ein anderes Kabel an der

Also Laut Handbuchern steht dort nichts von verdrillten Adern.
• 100 m mit 0,50 mm2 Leiterquerschnitt
• 300 m mit 1,50 mm2 Leiterquerschnitt.

Hatte nur mal bei einem 2-Meter Seriell-Kabel Probleme weil die Adern 
nicht oder falsch verdrillt waren.
Allerdings war das auch eine höhere Bitrate und ein schwächerer Pegel.

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe heute nun noch einmal versucht eine Verbindung zu der GB132T 
herzustellen. Leider hatte ich noch keinen Klinkenstecker, weshalb ich 
dann noch einmal ein anderes Kabel angeklemmt habe. Ohne Erfolg!
Selbst mit nur 10cm Kabeln zwischen dem Net-IO und dem orangenen 
RC-Stecker kann ich zwar Telegramme empfangen, aber der Servicekey 
erscheint nicht bei den Busteilnehmern.
Bei meiner GB142 habe ich die Platine noch einmal getestet, dort geht 
alles wie gewünscht.
Woran kann das denn liegen? Kennt die GB132T vielleicht noch gar keinen 
Servicekey weil sie eine andere/ältere Firmware hat?
Ich bin gerade ratlos wie ich dem EMS denn nun beibringen kann das nun 
ein "Servicekey" vorhanden ist.
Hat von euch vielleicht noch jemand eine Idee??? :-(

Gruß

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Benutzt du being beiden Brennern die selbe RC3x? Was sind denn deine 
Firmwareversionen?

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Benutzt du being beiden Brennern die selbe RC3x? Was sind denn deine
> Firmwareversionen?

Nein, es ist jeweils eine RC35 vorhanden. Bei der GB132T wurde die RC30 
mal gegen eine RC35 getauscht.
Die Versionen sind wie folgt:

GB132T:

RC35 1.06
UBA3 3.02
BCM Version 12
BCM Nummer 1006
BC10 2.01


GB142:

RC35 1.06
UBA3 3.05
BCM Version 14
BCM Nummer 1002
BC10 2.03


Die GB132 ist ein oder 2 Jahre älter als die GB142...

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
An den Versionen liegt es dann schon mal nicht. Ich habe UBA 2.05, BCM 9 
und BC10 2.00. Meine RC35 ist neuer (1.16), aber da 1.06 bei dir an der 
GB142 geht, ist es das wohl auch eher nicht.

Die EMS-Adapter-Platine ist in beiden Fällen die selbe, richtig? 
Ansonsten fällt mir auch nicht viel ein :(

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Die EMS-Adapter-Platine ist in beiden Fällen die selbe, richtig?

Ja, das ist die selbe...
Dann kann ich nur hoffen das es am Klinkenstecker geht. Da muss ich mir 
aber noch einen Stecker besorgen.
Hast Du die EMS-Adapter-Platine auch an dem orangenen Stecker am 
Klemmbrett auf der linken Seite angeschlossen?

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Kann ich grad nicht nach schauen; auf alle Fälle hängt die Platine bei 
mir an der Leitung, an der auch die RC35 hängt (letztere hängt im 
Wohnzimmer, nicht an der Heizung).

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> (letztere hängt im
> Wohnzimmer, nicht an der Heizung)

Die RC35 hängt bei mir in beiden Fällen an der Heizung.
Der RC Anschluss wird aber ja bestimmt einfach nur parallel zum Bus 
liegen...

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Die EMS-Wiki URL hat sich geändert:
http://wiki.thefischer.net

Die alte URL wird noch einge Zeit auch noch funktionieren

Falls noch die alte URL in der Adressleiste erscheint liegt das am Cache 
vom Browser.

Gruß
IngoF

von Andreas Z. (andreas_z15)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt nach einigen Problemen mein System mit dem Board von 
Jürgen und einem NetIO zum Laufen gebracht. Ich habe eine GB152 mit 
RC30. Es gibt 2 Heizkreise, HK1 ist ungemischt, HK2 gemischt. Der 
Raumtemperaturfühler am RC30 wird HK2 zugeordnet. Dieser wird an der 
RC30 auch richtig angezeigt aber nicht im Frontend. Hier kommt das 
berühmte 3200, wobei das auch nicht konstant ist. Bei mir fehlt der 
Telegramtyp 0xA3 (bzw. ist nur ganz kurz).

Ich habe jetzt festgestellt, dass 2 Telegramme mit der Raumtemperatur 
gelesen werden, einmal für HK1 (mit 0x7d = 3200) und für HK2 ( der 
richtige Wert.

IO: Got bytes 0xaa 0x55 0x13 0x10 00 0x3e 00 0x4 00 00 0x7d 00 00 00 0x5 
0x5 0xd 00 00 00 00 0x5 0x5f
MESSAGE[24.10.2015 23:47:06]: source 0x10, dest 0x00, type 0x3e, offset 
0, data: 0x04 0x00 0x00 0x7d 0x00 0x00 0x00 0x05 0x05 0x0d 0x00 0x00 
0x00 0x00 0x05
DATA: Raum-Solltemperatur = 0 °C
DATA: Raum-Isttemperatur = 3200 °C
DATA: HK1-Kennlinie = -10 °C: 5 °C / 0 °C: 5 °C / 10 °C: 13 °C
DATA: HK1-Solltemperatur = 5 °C

IO: Got bytes 0xaa 0x55 0x13 0x10 00 0x48 00 0x4 00 00 00 0xd7 00 00 0x5 
0x5 0x9 00 00 00 00 0x5 0x87
MESSAGE[24.10.2015 23:46:06]: source 0x10, dest 0x00, type 0x48, offset 
0, data: 0x04 0x00 0x00 0x00 0xd7 0x00 0x00 0x05 0x05 0x09 0x00 0x00 
0x00 0x00 0x05
DATA: Raum-Solltemperatur = 0 °C
DATA: Raum-Isttemperatur = 21.5 °C
DATA: HK2-Kennlinie = -10 °C: 5 °C / 0 °C: 5 °C / 10 °C: 9 °C
DATA: HK2-Solltemperatur = 5 °C

Es müsste also der Wert 0x7d für die Raumtemperatur ignoriert werden. An 
einem RCxx kann nur ein Raumfühler hängen.

Ist eigentlich geplant, das Web-Frontend mal auf 2 Heizkreise zu 
erweitern, oder wie könnte ich statt dem HK1 den HK2 verwenden ?

Andreas Z


Meine Versionen sind wie folgt :
UBA   3.05
BC10  2.02
RC30  2.08

: Bearbeitet durch User
von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
In meinem Repo wird 0x7d00 schon länger ignoriert. Siehe hier: 
https://github.com/maniac103/ems-collector/blob/master/collector/EmsMessage.cpp#L586 
- d.h. du musst nur mal deinen Collector updaten :)

Aus Telegramm 0xa3 wird nur die gedämpfte Außentemperatur entnommen, es 
ist also OK, wenn dieses Telegramm nur kurz ist.
An einer Unterstützung für HK2 im Frontend wäre ich auch interessiert, 
habe aber leider keine Zeit, das selber zu machen.

: Bearbeitet durch User
von Andreas Z. (andreas_z15)


Bewertung
0 lesenswert
nicht lesenswert
@ Danny

Vielen Dank für die Hilfe. Ich habe den Collector von Moosy verwendet, 
da ist das nicht drin. Ich habe heute Nacht noch eine andere Lösung 
gefunden. Beim Subtype HK1 parse ich die Raumtemperatur einfach nicht.

Was ist denn der Unterschied / Vorteil der beiden verschiedenen 
"Collectoren" ?
Für jemand der hier neu einsteigt ist es ein bisschen schwierig 
einigermaßen durchzublicken.

Trotzdem ist eine tolle Leistung was ihr da auf die Beine gestellt habt.
Ich konnte gestern bei mir schon die Brenneraufzeit verlängern indem ich 
die Hysterese erhöht habe.

Jetzt will ich das Ganze noch für die WW-Bereitung machen, da hier kurz 
vor erreichen des Sollwertes ganz schönt getaktet wird.

Andreas

: Bearbeitet durch User
von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Andreas Z. schrieb:
> Vielen Dank für die Hilfe. Ich habe den Collector von Moosy verwendet,

Ah, da ist der Fehler ;)

> Was ist denn der Unterschied / Vorteil der beiden verschiedenen
> "Collectoren" ?

Vorteil bei meinem Repo ist, dass es aktuell ist :)
Im Ernst: Es gibt inzwischen überhaupt keine Grund mehr, Moosys Repo zu 
verwenden. Zwischenzeitlich (aber schon einige Zeit her) hatte er darin 
neue Features entwickelt, aber die habe ich inzwischen alle übernommen. 
Bugfixes wiederum landen nur in meinem Repo, da Moosy ja inzwischen 
'verschwunden' ist.

> Für jemand der hier neu einsteigt ist es ein bisschen schwierig
> einigermaßen durchzublicken.

Karl hat mal ein nettes How-To für das 'Standard-Setup' mit dem Net-IO 
gemacht: http://wiki.thefischer.net/doku.php?id=wiki:ems:net_io
Wenn du anderweitige Ideen zu einer einsteigerfreundlichen Präsentation 
hast, nur raus damit ;)

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Karl hat mal ein nettes How-To für das 'Standard-Setup' mit dem Net-IO
> gemacht: http://wiki.thefischer.net/doku.php?id=wiki:ems:net_io
> Wenn du anderweitige Ideen zu einer einsteigerfreundlichen Präsentation
> hast, nur raus damit ;)

Hast ja schon den neuen Link genommen.

Leider muss ich gestehen dass dieser Link sehr oft nicht funktioniert.
Habe noch mehr Probleme damit beide Webserver auf eine Domain laufen zu 
lassen.

Also bis auf weiteres erst mal der alte Link
in diesem Fall also 
http://ems-gateway.myds.me/doku.php?id=wiki:ems:net_io

Allerdings wird diese alte URL auch erst heute abend wieder richtig 
funktionieren...

Fall die neue URL funktioniert kann es sein dass man noch auf einer 
etwas älteren Sicherheitskopie landet.

Gruß
Ingo

: Bearbeitet durch User
von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
So die EMS-Wiki ist jetzt über die neue Adresse erreichbar:
http://emswiki.thefischer.net

Das Problem war in meinem Firefox-Pofil. Es lief also von Anfang an 
Fehlerfrei...

: Bearbeitet durch User
von Andreas Zöller (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,

es läuft jetzt alles. Vielen Dank für deine Hilfe.

Kompilieren auf dem Raspberry Pi ist wirklich ein Geduldsspiel. Ich habe 
einen ganz alten mit nur 256MB Ram. Der ist wirklich an der Grenze.

Andreas

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
Andreas Zöller schrieb:
> es läuft jetzt alles

... schön! Und der Hintergrund? Dannys Repo, oder was?

> Der ist wirklich an der Grenze.

Beim kompilieren "ja". Ansonsten kann ich das nicht bestätigen. Hab' 
auch so einen, der macht noch ein paar andere Dinge (lighty, owfs, 
mysql, etc.)  nebenbei. :-)

Gruß aus der Wetterau

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Kann ich grad nicht nach schauen; auf alle Fälle hängt die Platine bei
> mir an der Leitung, an der auch die RC35 hängt (letztere hängt im
> Wohnzimmer, nicht an der Heizung).

Hallo,
ich habe heute den von Danny beschriebenen Zustand hergestellt.
RaumController über ein Kabel an Klemme RC verbunden.
Dazu parallel die AVR NET-IO Platine.

Ergebnis:
RaumController funktioniert
NET-IO kann nur empfangen, nicht senden!
Monitorwerte "Busteilnehmer" wird kein ServiceKey angezeigt


Wenn nun niemand mehr eine Idee hat werde ich an dieser Stelle wohl 
aufgeben müssen! :-(


Gruß
Dennis

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Wenn nun niemand mehr eine Idee hat werde ich an dieser Stelle wohl
> aufgeben müssen! :-(

Was hast Du denn für Messmöglichkeiten?
Digitales Seicher Oszilloskop (DSO) oder ähnliches ist vermutlich nicht 
vorhanden, oder?

Schon mit dem Klinkenstecker probiert?

Schon seltsam dass es an der einen Heizung funktioniert und an der 
anderen nicht.

Was hast Du denn für Busteilnehmer am Bus an der Heizung die nicht 
funktioniert? Gibt es da vielleicht schon ähnliche Hardware?

Sind auch alle vier parallel geschalteten Wiederstände im Sendeteil 
richtig angelötet. Könnte ja sein dass einer keinen richtigen Kontakt 
hat und die andere Anlage nur wegen anderen Toleranzen funktioniert. Hat 
die NetiO-Adapterplatine auch vier Widerstände?

Danny, hattest Du nicht auch die Software für den NetIO programmiert?
Gibt es da noch weitere Debugging-Optionen? Könnte man eventuell was 
"basteln"?


Das erinnert mich an meine (Marken)-HiFi-Anlage. Bei mir war die extrem 
stark am Rauschen. Beim Händler, Nachbarn und Freunden lief die 
einwandfrei. Störende Verbraucher waren auch nirgend zu sehen.
Habe nie herausbekommen woran es lag. Musste das nächst größere Modell 
kaufen.

Schätze mal die Stromversorgung/Das Netzteil für den NetIO ist das selbe 
wie bei an der anderen Anlage, oder?
Vielleicht zum Spass mal mit Batterien ausprobieren?
Irgendwelche Seventuell störenden Geräte sind nicht in Nähe?

: Bearbeitet durch User
von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Was hast Du denn für Messmöglichkeiten?
> Digitales Seicher Oszilloskop (DSO) oder ähnliches ist vermutlich nicht
> vorhanden, oder?

Leider nur ein ganz einfaches analoges...

Ingo F. schrieb:
> Schon mit dem Klinkenstecker probiert?

Nein, aber da habe ich dann ja auch fast keine Hoffnung mehr...

Ingo F. schrieb:
> Was hast Du denn für Busteilnehmer am Bus an der Heizung die nicht
> funktioniert? Gibt es da vielleicht schon ähnliche Hardware?

Es sind in beiden Fällen immer eine UBA ein BC10 und ein RC35 vorhanden.

Ingo F. schrieb:
> Sind auch alle vier parallel geschalteten Wiederstände im Sendeteil
> richtig angelötet. Könnte ja sein dass einer keinen richtigen Kontakt
> hat und die andere Anlage nur wegen anderen Toleranzen funktioniert. Hat
> die NetiO-Adapterplatine auch vier Widerstände?

Ich habe inzwischen auch 2 Adapterplatinen, bei beiden zeigt sich dieses 
Verhalten. Als Transistor wurde ein BC107 verbaut.

Ingo F. schrieb:
> Schätze mal die Stromversorgung/Das Netzteil für den NetIO ist das selbe
> wie bei an der anderen Anlage, oder?
> Vielleicht zum Spass mal mit Batterien ausprobieren?
> Irgendwelche Seventuell störenden Geräte sind nicht in Nähe?

Bei der funktionierenden Anlage habe ich es zunächst mit dem USB 
Anschluss vom Laptop getestet und nutze nun den USB Anschluss der 
Fritzbox als 5V Spannungsversorgung.
Bei der nicht funktionierenden habe ich es nun nur mit dem Laptop 
getestet.
Ohne EMS-Bus nimmt die Platine ca. 150mA auf...


Danke das Du Dir die Mühe machst und mir Hilfestellung gibst. :-)

von Ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> eider nur ein ganz einfaches analoges...

Na das hilft doch schon mal.
Am besten auf das Eingangssignal des Sendetransistors triggern und sehen 
was passiert.

Evtl mit Trenntrafo messen?!

In diesem Beitrag im zweiten Bild sieht man oben das Sendesignal. Der 
Busmaster wiederholt dann die Telegramme.
Beitrag "Re: Logamatic 2107 Schnittstelle"

zum generellen Telegrammaufbau:
http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-telegramme

Dennis schrieb:
> Nein, aber da habe ich dann ja auch fast keine Hoffnung mehr...

Da hilft nur ein Test um das herauszufinden.

Dennis schrieb:
> Bei der funktionierenden Anlage habe ich es zunächst mit dem USB
> Anschluss vom Laptop getestet und nutze nun den USB Anschluss der
> Fritzbox als 5V Spannungsversorgung.
> Bei der nicht funktionierenden habe ich es nun nur mit dem Laptop
> getestet.
> Ohne EMS-Bus nimmt die Platine ca. 150mA auf...

Na dann sollte das wohl nicht das Problem sein..

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Danny, hattest Du nicht auch die Software für den NetIO programmiert?
> Gibt es da noch weitere Debugging-Optionen? Könnte man eventuell was
> "basteln"?

Nicht wirklich :( Der NetIO-Code schiebt die auf dem Socket empfangenen 
Daten einfach in die serielle Schnittstelle rein, wenn er gepollt wird, 
da ist keine riesige Logik dahinter. Insofern ist dein Vorschlag, an der 
Basis des Sendetransistors zu messen, schon der richtige.

Das einzige relevante, was man an Debugging anschalten könnte, wäre die 
EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem 
ECMD-Port absetzen; die zweite Zahl hinter 'Packets 1byte' ist dann die 
Anzahl, wie oft der Master Adresse 0xb gepollt hat. Wenn das auf 0 
bleibt, stimmt etwas an der Heizungs-Konfiguration nicht (kann ich mir 
ehrlich gesagt aber nicht vorstellen).

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:
> Das einzige relevante, was man an Debugging anschalten könnte, wäre die
> EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem
> ECMD-Port absetzen

Die Option muss ich dann im Ethersex auf 1 setzen und mit kompilieren, 
oder?
Aktuell nutze ich nämlich das Hexfile aus dem Wiki...

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Hexfile aus dem Wiki

ECMD_PARSER, ECMD_TCP, etc sind im hex enthalten.
siehe auch:
http://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io#software

hth

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
@dennis

du könntest spasshalber mal die bus-spannung bei beiden geräten mit und 
ohne angeschlossenem adapter messen und vergleichen.

//niffko

von Niffko _. (niffko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
du könntest, je nach lust und laune, auch noch den bus-stecker testen, 
der für den anschluss von funktionsmodulen vorgesehen ist und hinten im 
gerät rumfliegt (siehe anhang).


//niffko

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> du könntest, je nach lust und laune, auch noch den bus-stecker testen,
> der für den anschluss von funktionsmodulen vorgesehen ist und hinten im
> gerät rumfliegt

Hallo,
ich habe gerade den Net-IO an die hintere Klemme angeschlossen. (Nachdem 
wir eine viertel Std. gesucht haben)
Leider wird er immer noch nicht erkannt.

Danny B. schrieb:
> Das einzige relevante, was man an Debugging anschalten könnte, wäre die
> EMS_DEBUG_STATS-Option. Dann kann man das 'ems stats'-Kommando auf dem
> ECMD-Port absetzen; die zweite Zahl hinter 'Packets 1byte' ist dann die
> Anzahl, wie oft der Master Adresse 0xb gepollt hat. Wenn das auf 0
> bleibt, stimmt etwas an der Heizungs-Konfiguration nicht (kann ich mir
> ehrlich gesagt aber nicht vorstellen).

Statistik sieht wie folgt aus:
Bytes total:12134
Bytes good:2008
Bytes dropped:0
Packets good:91
Packets bad:0
Packets 1byte:10046 61
Packets ack:0 nack:0
Overflow:0
Max fill:2

Das heißt doch die Adress 0x0b wurde 61x gepollt, oder?

Gruß

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
So wie Danny das beschrieben hat ist das wohl die Anzahl wie oft die 
Busadress 0x0b (11) gepllt wurde.

Wichtig ist allerdings dabei die Zeit.
Es werden alle möglichen Adressen der Reihe nach angepollt. Weiß nicht 
mehr wie oft das ist. Meine es wären irgendwas über zwei Sekunden.

Wenn ein Busteilnehmer auf diese Anfrage Antwortet wird kurz darauf das 
Polling erhöht und wird mehrmals pro Sekunde gepollt.

Also scheint es wohl Probleme mit dem Sendeteil zu geben.
Der NetIO bekommt das Polling und antwortet darauf.

Wenn ich Danny richtig verstanden habe wird der Counter nur erhöht wenn 
der NetIO auf sein Polling sendet.

Also wird wohl kein Weg am Oszilloskop vorbeigehen. Am besten auf das 
Sendesignal vom NetIO am NetIO-Ausgang triggern lassen und dann am 
EMS-Bus mitloggen. Der EMS-Bus sollte dann um einige Millivolt 
zusammenbrechen. Hatte ja den Link zum Oszillogramm genannt.

Ein Test über Klinkenstecker kann auch nciht schaden, wird aber 
vermutlich auch kein anderes Ergebnis liefern.

Gruß
Ingo

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Wenn ein Busteilnehmer auf diese Anfrage Antwortet wird kurz darauf das
> Polling erhöht und wird mehrmals pro Sekunde gepollt.

Dann erscheint der Busteilnehmer auch im RC

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Also wird wohl kein Weg am Oszilloskop vorbeigehen

Habe ich gerade schon angeschlossen... :-)

Die Signale des Bus sehe ich.
An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!
Deshalb kommt auch nix auf dem Bus an.
Aber wieso wird der Transistor nicht angesteuert???

von Dennis (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Die Signale des Bus sehe ich.
> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!

Hier mal ein Versuch ein Bild von dem Bus (Kanal B) und der 
TransistorBasis (Kanal A) zu machen.
Man kann leider nicht ganz so gut die Signale sehen...

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Dennis schrieb:
>> Die Signale des Bus sehe ich.
>> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!
>
> Hier mal ein Versuch ein Bild von dem Bus (Kanal B) und der
> TransistorBasis (Kanal A) zu machen.
> Man kann leider nicht ganz so gut die Signale sehen...

Bei der Y-Auflösung kannst Du dort nichts sehen. Das Signal was gesendet 
wird ist unter 1V.
Die X-Auflösung ist auch viel zu klein.

Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen 
(kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern.

Aber scheinbar hat es zum triggern gereicht, Aber die Y-Auflösung ist 
auch zu gering um was erkennen zu können.

von Taner A. (taner_a)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich implementiert Adapter mit AVR-NET-IO Board für meine Buderus GB112 
Kessel mit RC35. Zunächst Ethersex, die aus dem Wiki heruntergeladen 
wird, wurde verbrannt und ATmega644P Sicherungen sind festgelegt, wie 
beschrieben. Ich überprüfte, dass AVR-NET mit Ethersex läuft 
erfolgreich. aber keine LED-Leuchten eingeschaltet am Adapter, wenn ich 
ihn zu RC in paralel mit RC35. Ich konnte keine Daten von Testkollektor 
nicht sehen, auch.

Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft 
es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt, 
Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem 
nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die 
Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ... 
Nochmals vielen Dank für das Projekt gerne ...

PS: Sorry für mein Deutsch

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> An der Basis des Transistors sehe ich aber gegen Masse keine Peaks!
> Deshalb kommt auch nix auf dem Bus an.
> Aber wieso wird der Transistor nicht angesteuert???

Was sagt denn der entsprechende Pin auf dem Pfostenstecker?

Taner A. schrieb:
> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft
> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,
> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem
> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die
> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...
> Nochmals vielen Dank für das Projekt gerne ...

Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung 
kommen mir zu wenig vor. IIRC sind das doch 12V?

von Juergen O. (juergen_o)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Wichtig ist allerdings dabei die Zeit.
> Es werden alle möglichen Adressen der Reihe nach angepollt. Weiß nicht
> mehr wie oft das ist. Meine es wären irgendwas über zwei Sekunden.

Mal schnell nachgeschaut:
bei inaktiven Adressen liegt das Polling-Intervall bei ca 1,25sec.
15-11-06 6:47:05 45692.544 83 81 {4} 55 AA 83 81 D9 3E 3C 56 80 36 B9 02 04 00 |8B 00 E5 1A 
15-11-06 6:47:06 46945.048 83 81 {4} 55 AA 83 81 DA 3E 3C 56 18 53 CC 02 04 00 |8B 00 E5 1A 
15-11-06 6:47:08 48202.752 83 81 {4} 55 AA 83 81 DC 3E 3C 56 00 84 DF 02 04 00 |8B 00 E5 1A 
15-11-06 6:47:09 49455.460 83 81 {4} 55 AA 83 81 DD 3E 3C 56 64 A1 F2 02 04 00 |8B 00 E5 1A 
Aktive Busteilnehmer hingengen alle ~50ms (bsp. 0x90) abgefragt:
15-11-06 6:47:09 49712.100 83 81 {4} 55 AA 83 81 DD 3E 3C 56 E4 8B F6 02 04 00 |90 00 E5 1A 
15-11-06 6:47:09 49763.511 83 81 {4} 55 AA 83 81 DD 3E 3C 56 B7 54 F7 02 04 00 |90 00 E5 1A 
15-11-06 6:47:09 49827.203 83 81 {4} 55 AA 83 81 DD 3E 3C 56 83 4D F8 02 04 00 |90 00 E5 1A 
15-11-06 6:47:09 49917.433 83 81 {4} 55 AA 83 81 DD 3E 3C 56 F9 AD F9 02 04 00 |90 00 E5 1A 
15-11-06 6:47:09 49968.740 83 81 {4} 55 AA 83 81 DD 3E 3C 56 64 76 FA 02 04 00 |90 00 E5 1A 

> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung
> kommen mir zu wenig vor. IIRC sind das doch 12V?
Hier sind's ca 15V mit einer ESP-Bridge, 13V wenn zwei Bridges 
angeschlossen sind. Der Signalhub (eingehend) liegt bei ca 4-5V.

Die ESP-Bridge, die vom EMS-Bus versorgt wird, zieht ca. 50mA.

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen
> (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern.

Ist es nicht so das die Basis vom OP mit 5V angesteuert wird?
Deshalb hatte ich Kanal A mit 5V/d eingestellt...

Als ich es dann wieder abgebaut hatte habe ich auch daran gedacht doch 
besser noch einmal den Eingang des OP bzw. den TX-Pin des µC zu messen.
Werde ich heute noch einmal versuchen...

Schade nur das ich den Verlauf nicht speichern kann. :-(

von Ingo F. (ingof)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Ist es nicht so das die Basis vom OP mit 5V angesteuert wird?
> Deshalb hatte ich Kanal A mit 5V/d eingestellt

Habe mir gerade mal die Schaltung angesehen.
http://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io#hardware

Normalerweise sollte der OP-Ausgang hochohmig sein und wird über einen 
4,7KOhm Widerstand auf +5Volt gezogen. Der OP zieht beim Senden die 
Basis vom Transistor auf 0V.
Vermutlich hast Du mit Deiner Messchnur den Eingang auf Dauerhaft-0 
gezogen.
Wenn ich das Bild richtig Deute hast Du dort durchgehen 0,17V

Also am besten vor dem OP messen.

Für den EMS-Bus musst Du allerings die Empfindlichkeit erhöhen. Die 
Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann 
vom Master nochmals für alle wiederholt wird.

Aber die Zeitachse sollte auch weiter auseinander gezogen werden.

: Bearbeitet durch User
von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Normalerweise sollte der OP-Ausgang hochohmig sein und wird über einen
> 4,7KOhm Widerstand auf +5Volt gezogen. Der OP zieht beim Senden die
> Basis vom Transistor auf 0V.
> Vermutlich hast Du mit Deiner Messchnur den Eingang auf Dauerhaft-0
> gezogen.

Das würde ja bedeuten der Bus ist dauerhaft mit den 220 Ohm belastet und 
wird beim senden dann "entlastet"?


Ingo F. schrieb:
> Die
> Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann
> vom Master nochmals für alle wiederholt wird.

Wie muss ich mir das vorstellen?
Wie man auf dem Bild sieht wird der Bus von ca. 14,85V bei Telegrammen 
auf ca. 14,3V runtergezogen.
Würde man beim senden dann die Telegramme oberhalb der 14,85V Linie 
sehen?

von Ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Das würde ja bedeuten der Bus ist dauerhaft mit den 220 Ohm belastet und
> wird beim senden dann "entlastet"?

Ups. habe mich vom GND täuschen lassen das oben liegt.
Das ist ein NPN-Transistor. Also die Basis vom Tranistor wird vom OP 
dauerhaft auf 0 gezogen. Im Sendefall zieht der 4,7kOhm Widerstand die 
Basis hoch. Das bedeutet aber auch dass an der Basis etwa 0,7V abfallen

Dennis schrieb:
> Ingo F. schrieb:
>> Die
>> Sendestufe erzeugt nur ein Signal von 0,5Volt auf dem EMS-Bus der dann
>> vom Master nochmals für alle wiederholt wird.
>
> Wie muss ich mir das vorstellen?

Wie in diesem Bild:
https://www.mikrocontroller.net/attachment/191441/EMS_Burst2.jpg

Die Grüne Kurve ist der EMS-Bus. Das große Signal ist der Master und das 
kleine Signal oben ist der NetIO

von Ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingof schrieb:
> Die Grüne Kurve ist der EMS-Bus. Das große Signal ist der Master und das
> kleine Signal oben ist der NetIO

Man sieht dort zwei Byte Polling. Das wird dann vom NetIO beantwortet. 
Der Master widerholt sofort darauf jedes Byte.

insgesamt also 6 Bytes.

von Taner A. (taner_a)


Bewertung
0 lesenswert
nicht lesenswert
Danny B. schrieb:

> Taner A. schrieb:
>> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft
>> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,
>> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem
>> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die
>> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...
>> Nochmals vielen Dank für das Projekt gerne ...
>
> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung
> kommen mir zu wenig vor. IIRC sind das doch 12V?

wenn ich ziehen Sie das RC35 ist die Spannung am RC 12 Volt. Aber wie 
gesagt, bevor die Spannung ist etwa 5-6 Volt, wenn RC35 verbunden

: Bearbeitet durch User
von Ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Taner A. schrieb:
> Danny B. schrieb:
>
>> Taner A. schrieb:
>>> Ich vermute, dass die Umsetzung der Adapter aber ich zweimal überprüft
>>> es. Die DC-Spannung am RC-Kabel liegt bei etwa 5 Volt,
>>> Vergleichsspannung, EXT Spannung in Ordnung sind. Ich konnte das Problem
>>> nicht finden. Gibt es einen HW Fehlerdaten für den Adapter? die
>>> Komponente, die Spannung etc? Ich werde für jede Hilfe, Empfehlung ...
>>> Nochmals vielen Dank für das Projekt gerne ...
>>
>> Vielleicht bin ich ja schief gewickelt, aber 5V auf der EMS-Leitung
>> kommen mir zu wenig vor. IIRC sind das doch 12V?
>
> wenn ich ziehen Sie das RC35 ist die Spannung am RC 12 Volt. Aber wie
> gesagt, bevor die Spannung ist etwa 5-6 Volt, wenn RC35 verbunde

Sorry nicht so ganz vertstanden. Am Bus sollte immer etwas über 12 Volt 
sein.
Wann sind es 5-6 Volt? Wenn Du die Platine Anschließt? Wenn das so ist 
stimmt irgendwas mit der Platine nicht.

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingo F. schrieb:
> Bei der Y-Auflösung kannst Du dort nichts sehen. Das Signal was gesendet
> wird ist unter 1V.
> Die X-Auflösung ist auch viel zu klein.
>
> Die Basis selbst am Transistor wird vermutlich bei 0,7 Volt liegen
> (kenne jetzt die Schaltung nicht) AM besten am NetIO Ausgang triggern.
>
> Aber scheinbar hat es zum triggern gereicht, Aber die Y-Auflösung ist
> auch zu gering um was erkennen zu können.

Hallo,
ich habe gerade Vergleichsmessungen zwischen meiner funktionierenden 
GB142 und der GB132T gemacht.
Leider kann ich das Scopemeter nicht kleiner als 20ns/d auf der 
Zeitachse einstellen.

Ich sehe aber in beiden Fällen ähnliche Signale:
- an der Transistorbasis liegen ca. 60mV an und man sieht dann Peaks von 
700mV
- am Pin5 des OP liegen in beiden Fällen ca. 630mV
- an Pin6 des OP liegen ca. 5V und man sieht auch Peaks in Richtung 0V

Einzig der Intervall in der diese Peaks an Basis bzw. TX Ausgang des µC 
kommen unterscheidet sich. Vermutlich weil bei der GB142 die Adresse 11 
als vorhanden erkannt wurde.


Ohne Speicher Oszilloscop werde ich hier aber wohl nicht mehr weiter 
kommen, richtig? Wieviel MHz sollte das Oszilloscope denn können?


Gruß

von Taner A. (taner_a)


Bewertung
0 lesenswert
nicht lesenswert
Ingof schrieb:
> Sorry not quite vertstanden. At the bus should always about 12 volts
> be.
> When there are 5-6 Volt? If you connect the board? If so
> Is something wrong with the board.

beim RC35 ist verbunden GB112, die RC voltzahl 5-6 Volt. (der adapter 
ist nicht angeschlossen)

RC35 ist mit GB112 mit 20 Meter kabel verbunden ...

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
@Taner
bad news ... im GB112 arbeitet ein UBA1.5 und der kommuniziert nicht 
über EMS. mir ist leider auch nicht bekannt, dass das dort verwendete 
protokoll schon "reversed" wurde.

//niffko

von Taner A. (taner_a)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> @Taner
> bad news ... im GB112 arbeitet ein UBA1.5 und der kommuniziert nicht
> über EMS. mir ist leider auch nicht bekannt, dass das dort verwendete
> protokoll schon "reversed" wurde.
>
> //niffko

Oooopsss.... :(

gibt es eine andere andere Protokoll vom RC35 verwendet?

soweit ich weiß, RC35 nutzen nur EMS-Bus

: Bearbeitet durch User
von Ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Taner A. schrieb:
> Ingof schrieb:
>> Sorry not quite vertstanden.

do you use google-translator?
I think it is better to write in english.

Do you have 12V at the bus if nothing is connected?
And if you connect the RC35 there are at first 12V and after a while 
there is only 5V?

In the RC35 manual i can only find the EMS-Bus.
Maybe the RC35 switches to an other Bussystem.

But it seems that the RC35 changes the bussystem.

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
gb112 definitely cant't talk ems! there's a reason why rc35 can handle 
this. rc35 is the replacement unit for the obsolete erc-controller, so 
it can switch protocol and hw-interface. rc30 can neither be plugged on 
pre-ems systems.

//niffko

von Taner ASLAN (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ingof schrieb:
> Do you use Google translator?
> I think it is better to write in English.
>
> Do you have 12V at the bus if nothing is connected?
> And if you connect the RC35 there are at first 12V and after a while
> there is only 5V?
>
> In the RC35 Manual I Can Only Find the EMS bus.
> Maybe the RC35 switches to an other bus system.
>
> But It Seems That the RC35 changes the bus system

Yes that's right. First 12V, after I connect GB112 RC to RC35, it 
reduces to 5-6 volts.

von Taner ASLAN (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> GB112 definitely cant't talk ems! There's a reason why RC35 can handle
> this. RC35 is the replacement unit for the obsolete ERC controller, so
> it can switch protocol and hardware interface. RC30 can neither be
> plugged on pre-ems system.
>
> // niffko

Thanks for the info, niffko.

But km200 web system can talk with rc35 (I think via ems) so that, when 
rc35 is connected to gb112, can I talk with rc35 via ems ?

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
not sure i get you right, but both km200 and rc35 are in fact 
bus-clients. bus functionality is provided by the burner-automat acting 
as bus-master (UBA1.5 in your case, non-ems). so if there's no 
ems-bus-master, no client can talk ems to one another.

//niffko

von F. F. (pic18f)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich benutze vom Ingo die EMS-Gateway Hardware, mit ENC28J60 
Netzwerkmodul. Mich würde interessieren wie ich die Seite 
"ems-php-webinterface-master" benutzen kann. Ich habe kein Raspi. Ist es 
möglich direkt vom PC mit der Web-Seite über Gateway auf die Heizung 
zuzugreifen? Wie gebe ich den Port und die IP-Adresse ein? Kann man auch 
die Heizungseinstellungen vornehmen? Benötige ich evtl. noch den 
ems-collector?

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, genauso läuft es bei mir....

EMS–Gateway am Linux-PC mit Collector, Frontend und mySQL. Habe es aber 
nicht hinbekommen MySQL und Frontend auf verschiedenen Servern laufen zu 
lassen.

Mit dem Windows-PC gibt es laut Danny eine Version ohne MySQL.

von ingof (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Netzwerk-Interface wird natürlich am EMS–Gateway benötigt....

von passuff (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Ich habe versucht nach dem Wiki und den Forenbeiträgen ein System aus 
Adapterplatine, AVR NET IO und Raspberry aufzubauen. Leider nur mit 
dürftigem Erfolg, denn scheinbar haben alle Teilsysteme Fehler:

1. Adapterplatine

Leider bin ich mit dem Schaltplan und den Layouts weniger gut 
zurechtgekommen als meine Vorredner. Meiner Meinung nach hat sich auch 
ein Fehler im Eagle Schaltplan oder im Platinenlayout eingeschlichen, da 
die Operatoren vertauscht sind. Zumindest passt das Layout nicht zum 
Schaltplan. Ich habe mich daher zunächst schwer getan, alle Bauteile auf 
dem Layout zu identifizieren. Anbei mein Bestückungsplan und Korrekturen 
im Eagle Schaltplan. Wäre schön wenn sich jemand diese ansehen könnte, 
da ich wenig Erfahrung habe und vielleicht schon hier ein Fehler liegt.

2. AVR NET IO

2.1. ATMEGA 644P getauscht mit Hex aus dem WIKI geflasht
2.2. Fusebits gebrannt und auch überprüft
2.3. IP und MAC Adresse entsprechenf geändert. Was ist mit dem 
Gateway? Trage ich hier meine Routeradresse ein? Sobald ich das mache, 
ist mein AVR NET IO selsbt nach einem restart nciht mehr ansprechbar un 
einzige Abhilfe ist ihn erneut zu flashen..
Ich habe das Gateway daher zunächst auf dem Standartwert gelassen.

2.4. ethersex page angesprochen : funktioniert

2.5 http://<meineIP>/ecmd?ems%20stats :

  mit angeschlossenem Adapter und EMS BUS:

  Bytes total:0
  Bytes good:0
  Bytes dropped:0
  Packets good:0
  Packets bad:0
  Packets 1byte:0 0
  Packets ack:0 nack:0
  Overflow:0
  Max fill:0

  mit angeschlossener Platine ohne angeschlossenem EMS BUS:

  Bytes total:4470
  Bytes good:19
  Bytes dropped:0
  Packets good:19
  Packets bad:838
  Packets 1byte:2670 0
  Packets ack:0 nack:0
  Overflow:0
  Max fill:4

Die Platine habe ich überprüft, optisch scheint alles in Ordnung zu 
sein. Der EMS Anschluss scheint durch die Dioden verpolunempfindlich, 
richtig? Vielleicht habe ich die Platine doch falsch bestückt?

3. Raspberry
später mehr dazu. Ich möchte euch nicht verwirren

von Seppl F. (passuff)


Bewertung
0 lesenswert
nicht lesenswert
Habe noch vergessen zu erwähnen welche Heizungskonfiguration ich 
verwende:

Buderus Logamatic U124-11 mit UBA und RC(weder 30 noch 35!!).
Hier die Beschreibung meiner RC:

http://documents.buderus.com/download/pdf/file/5646994.pdf

Ist aber wohl auch ein EMS BUS Gerät.

von IngoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
passuff schrieb:
> die Operatoren vertauscht sind

Das ist egal. Beide Comperatoren sind untereinander austauschbar.

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Seppl F. schrieb:
> Buderus Logamatic U124-11 ...

die U124 ist kein ems-gerät. das wird nix, sorry ...


@ingo
ich denke, es wird langsam zeit für eine blacklist in der wiki.


//niffko

von Seppl F. (passuff)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> Seppl F. schrieb:
>> Buderus Logamatic U124-11 ...
>
> die U124 ist kein ems-gerät. das wird nix, sorry ...
>
>
> @ingo
> ich denke, es wird langsam zeit für eine blacklist in der wiki.
>
>
> //niffko

Oh jeh. Das wäre natürlich mehr als ungünstig. Kann es aber immer noch 
nicht ganz glauben.

Laut Buderus Kundendienst kann ich meine U124 auf eine RC35 
Bedieneinheit umrüsten. Das war mir allerdings zu teuer und auch nicht 
ausreichend funktionell, daher habe ich mich nach Alternativen 
umgeschaut. So kam ich zum EMS Gateway...
Ich schreibe dem Buderus Kundendienst jetzt erst einmal....

von IngoF (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niffko _. schrieb:
> ich denke, es wird langsam zeit für eine blacklist in der wiki.

ist schon passiert.

Wusste nicht was ich wohin schreiben sollte.
Habe es erst mal so gelöst:
http://emswiki.thefischer.net/doku.php?id=wiki:ems:ems-bus

Hoffe ich habe nicht falsches geschrieben...

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Seppl F. schrieb:
> Laut Buderus Kundendienst kann ich meine U124 auf eine RC35
> Bedieneinheit umrüsten.

das ist korrekt. heißt aber nicht, dass die kommunikation über ems 
erfolgt. siehe Beitrag "Re: EMS > Adapter > NetIO > Raspi" .

Seppl F. schrieb:
> Ich schreibe dem Buderus Kundendienst jetzt erst einmal....

tust du hier gerade ;)

IngoF schrieb:
> [Blacklist]Hoffe ich habe nicht falsches geschrieben...

passt. ich mach mal die komplette liste fertig und stelle sie hier rein.


//niffko

von Seppl F. (passuff)


Bewertung
0 lesenswert
nicht lesenswert
Hatte mir gerade die Serviceanleitung der RC35 durchgelesen und da fiel 
es mir wie Schuppen von den Augen. Nachrüstbar heißt, wie du schon 
geschrieben hast, nicht zwangsläufig, dass meine Anlage auch EMS 
spricht. ?UCK..
Gibt es Erkenntnisse ob man die RC35 als Gateway nutzen kann und sich 
mit dem hier beschriebenen System draufsetzen kann?

von Niffko _. (niffko)


Bewertung
0 lesenswert
nicht lesenswert
Geräte ohne EMS-Bus:

  U104
  U112
  U114
  U122
  U124
  GB102
  GB112
  Linea Kombi 23
  GB122



//niffko

von Olaf K. (korky2)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ingo F.,
hallo Zusammen,

ich versuche mich auch an der Anschaltung. Adapterplatine muss ich noch 
zusammen bauen, dann ...

Leider bin ich im Wiki (wiki:ems:net_io) auf so manche "Eigenheiten" 
gestoßen. Welche ich wohl nicht verstehe. Bzw. mit der Bitte um 
Korrektur.

Bei der Ethersex-Software sind die Konfigurationsschritte gut erklärt. 
Aber was muss bei
Protocols ---> [*] EMS Support ---> EMS USART
auswählen/eintragen werden? Ich habe dort jetzt eine 1 stehen. Richtig?

Software auf dem Linux-Rechner (Raspian/Debian). Hier fehlt IMHO einige 
„-dev“
Wenn man „libmysql++“ installieren will klappt das hier* nicht, weil 
apt-get meint alles zu nehmen was libmysql zu tun hat/anfängt. Das war 
hier unauflösbar.
(Auch müsste bei libboost1.50-all / libboost1.49-all noch ein „-dev“ 
dran)

Auf der Wiki-Seite ist zur Datei „/etc/default/ems-collector“ ein 
Eintrag falsch:
SERIALDECIVE="tcp:192.168.XXX.XXX"
Dieses sollte sicherlich SERIALDEVICE="tcp:192.168.XXX.XXX:7950" heißen.
(V und C vertauscht und Port nicht vorhanden)
Sonst bekomme ich den collectord nicht am laufen. Bzw. beendet sich 
sofort wieder.


Viele Grüße
Olaf

hier* = Rasperry PI mit Raspian 7.8 oder x86er mit Debian 7.9

von F. F. (pic18f)


Bewertung
0 lesenswert
nicht lesenswert
ingof schrieb:
> Mit dem Windows-PC gibt es laut Danny eine Version ohne MySQL.

Hallo Ingo,
ich bekomme keine Verbindung zu ems-php-webinterface-master mit Windows 
PC. Gibt es eine Möglichkeit die IP einzustellen? Habe die IP mit 
collectord.exe eingegeben. Wie ich Mysql einrichte weiß ich auch nicht. 
Ich habe eine kostenlose Website mit bplaced eingerichtet. Außerdem 
würde ich auch gerne mit dem Android Handy auf die Werte zugreifen.

Im Moment benutze ich die von mir erweitere HTML Seite von Jürgen S. 
Hier kann ich die IP einstellen und auch übers Internet die Werte 
abfragen.

Viele Grüße
Franz

von Peter W. (piet61)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
habe vor einiger Zeit diesen Thread und das dazugehörige Wiki gefunden 
und bin begeistert.
Also habe ich mir die Komponenten bei Pollin und Reichelt bestellt und 
habe mit der NetIO Platine dem Flashen des ATmega644P begonnen - und 
stoße bereits auf die ersten Probleme :-(

Habe das fertige Hex-File mit PonyProg und einem AMTEL Evaluations-Board 
auf den 644P geflasht - auch die Fuses gemäß dem Thread angepasst.
Der Zugriff per LAN funktioniert - ich kann per ECMD Kommando die Werte 
(MAC, IP, Gateway etc.) setzen und sie auch per ECMD?reset aktivieren, 
doch leider werden die eingestellten Werte nicht dauerhaft gespeichert.
Sobald ich die Spannungsversorgung des NetIO Boards unterbreche 
'vergisst' es alle zuvor gemachten Einstellungen und setzt sich wieder 
auf die Standardeinstellungen zurück.
Habe schon verschiedene Vorgehensweisen durchprobiert - leider bisher 
ohne Erfolg :-(

Hat jemand eine Idee, woran das liegen könnte und was ich machen kann, 
um die Netzwerkeinstellungen dauerhaft zu speichern?

Danke für die Unterstützung :-)

piet

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
Peter W. schrieb:

< ... kann per ECMD Kommando die Werte (MAC, IP, Gateway etc.) setzen
< und sie auch per ECMD?reset aktivieren. ...

Hi Piet,

"reset" weglassen. ;)

hth
Karl M.

von Peter W. (piet61)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl,
vielen Dank für die schnelle Rückmeldung - aber an dem Reset Befehl 
liegt es wahrscheinlich nicht.
Wenn ich die Stromversorgung vom NetIO Board mit dem geflashten 644P 
einschalte, dann sind die default Netzwerkeinstellungen aktiv.
Ich kann dann mit den ECMD Kommandos über den WEB Browser die 
Einstellungen verändern. Die geänderten Einstellungen werden aber nicht 
aktiv (bis auf die MAC Adresse).
Bei der Abfrage der geänderten Werte werden immer noch die Default 
Einstellungen zurückgegeben (IP, Gateway).
In diesem Thread wird der Hinweis gegeben, dass ein Neustart 
erforderlich ist, um die geänderten Einstellungen zu aktivieren. Dies 
funktioniert bei mir aber leider nicht. Wenn ich nach der Anpassung die 
Stromversorgung unterbreche, sind nach dem Neustart wieder die 
Standardeinstellungen aktiv.
Wenn ich nach der Anpassung der Netzwerkeinstellungen den Reset Befehl 
sende, dann sind die neuen Einstellungen aktiv - das Board ist dann auch 
über die geänderte IP erreichbar und die Abfrage der Parameter über ECMD 
liefert auch die geänderten Einstellungen zurück.
Aber ein anschließender Neustart (durch unterbrechender Stromversorgung) 
setzt alle Einstellungen wieder zurück.

Bin für jeden Tip dankbar :-)

Viele Grüße

Piet

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
Sers Piet,

bei mir geht's so:
http://192.168.100.151/ecmd?ip 192.168.100.152 
-> ok
reboot (vulgo: Stecker raus)
http://192.168.100.152/ecmd?ip
-> 192.168.100.152

Auf das Netzwerksegment (Subnetz) achten!

Gruß aus der Wetterau und
Frohes Fest an Dich und alle Mitleser!
Karl M.

von Peter W. (piet61)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl, hallo Forum,

frohe Weihnachten 2. Teil an alle ;-)

Bei mir sieht es folgendermaßen aus:
NetIO Adapterplatine direkt verbunden mit dem LAN Anschluss von einem 
PC.
Netzwerkadresse am PC auf 192.168.0.1 eingestellt

http://192.168.0.0/ecmd?ip
-> 192.168.0.0

http://192.168.0.0/ecmd?ip 192.168.1.60
-> OK

Reboot
IP Adresse vom PC umstellen auf 192.168.1.61

http://192.168.1.60/ecmd?ip
-> 192.168.1.60
http://192.168.1.60/ecmd?mac
-> ff:ff:ff:ff:ff:ff

http://192.168.1.60/ecmd?mac 00:22:f9:01:d1:e2
-> OK

http://192.168.1.60/ecmd?mac
-> 00:22:f9:01:d1:e2

Reboot
http://192.168.1.60/ecmd?ip
-> Keine Antwort von der Net-IO Platine
IP Adresse vom PC umstellen auf 192.168.0.1
http://192.168.0.0/ecmd?ip
-> 192.168.0.0

Die Platine hat die gemachten Einstellungen 'vergessen'.

Gibt es bei den Einstellungen eine bestimmte Reihenfolge, die 
einzuhalten ist?
Ich habe schon verschiedene Varianten ausprobiert, leider bisher ihne 
Erfolg. Ich schaffe es nicht, die Netzwerkeinstellungen der NetIO 
Platine dauerhaft zu speichern.

Beim Durchtesten der verschiedenen Parameter habe ich festgestellt, dass 
ein 'ecmd?reset' die eingestelten Parameter aktiviert - ich kann also 
die MAC Adresse, die IP Adresse, die Netzwerkmaske und das Gateway 
einstellen und nach einem 'ecmd?reset' sind die eingestelltn Parameter 
aktiv und die Platine ist in meinem Netzwerk problemlos erreichbar - 
nach einem PowerCycle sind allerdings wieder die Default Einstellungen 
aktiv.

Wo genau werden diese Daten eigentlich gespeichert?
Oder kann jemand sagen, an welcher Stelle die Netzwerkparameter in dem 
Hex File hinterlegt sind? Dann könnte ich die direkt in das Hex-File 
integrieren...

Oder hat jemand noch eine andere Idee, wie ich die Netzwerkparameter 
dauerhaft gespeichert bekomme?

Vielen Dank!

piet

von peter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eventuel sind deine Fusebits nicht richtig gesetzt...

von Karl M. W. (charlie-w)


Bewertung
0 lesenswert
nicht lesenswert
Peter W. schrieb

> Oder hat jemand noch eine andere Idee, wie ich die Netzwerkparameter
> dauerhaft gespeichert bekomme?

Den hex mit gewünschten Einstellungen selber backen, siehe:
http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io#software

Readya
Karl M.

von Olaf K. (korky2)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich wollte mich herzlich bei allen beteiligten Personen bedanken.

Gestern habe ich endlich die Platine anschließen können. Provisorisch.
Nach ein paar „Streitigkeiten“ mit meinem Linuxserver läuft heute alles 
wie gewünscht.

Vielen Dank!

Viele Grüße
Olaf

von Matthias F. (pullmoll)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe die EMS-Adapterplatine zweimal vergeblich aufgebaut. Ich habe 
leider zwei linke Hände dafür.

Ich bekomme via telnet auf collectord (tcp:7777) nur ein Timeout auf 
getversion.
Via ecmd ems stats bleiben alle Werte auf Null.

Der EMS-Bus gehört zu einer GB-172 und sollte prinzipiell funktionieren.

Wenn jemand einmal eine Platine (bestückt oder unbestückt ist egal) an 
mich veräußern könnte und sich bei mir meldet, wäre ich sehr dankbar.

von Olaf K. (korky2)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

> Via ecmd ems stats bleiben alle Werte auf Null.
Ist in dem NET-IO (o.ä.) ein ATmega644P bzw. ATmeda1284P gesteckt?
(Der ATmega644-20PU ist falsch es muss mindestens der ATmega644P 
-20PU sein)

von Matthias F. (pullmoll)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort Olaf.

Es ist das Experimentierboard von Ulrich Radig

http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Ist der zweite usart hier entscheidend?

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Ist der zweite usart hier entscheidend?

Da ich mal nicht davon ausgehe, dass du die RS232-Buchse samt MAX232 
runtergerissen hast: ja, ist sie, da darüber die EMS-Kommunikation 
läuft. Wenn du den MAX232 abbaust, kannst du natürlich auch den EMS 
daran anschließen und Ethersex entsprechend umkonfigurieren, dann reicht 
auch ein 644 ohne P.

: Bearbeitet durch User
von Matthias F. (pullmoll)


Bewertung
0 lesenswert
nicht lesenswert
Ein frohes neues Jahr wünsche ich.

Danny B. schrieb:
> Da ich mal nicht davon ausgehe, dass du die RS232-Buchse samt MAX232
> runtergerissen hast: ja, ist sie, da darüber die EMS-Kommunikation
> läuft. Wenn du den MAX232 abbaust, kannst du natürlich auch den EMS
> daran anschließen und Ethersex entsprechend umkonfigurieren, dann reicht
> auch ein 644 ohne P.

Ich habe den MAX232 nun runtergerissen und die Pins des Atmega644 so 
verdrahtet:

m644        |LM393P
==================
14 (RXD)PD2 | Pin4
15 (TXD)PD1 | Pin6



Es werden Daten auf dem EMS-Bus empfangen wo auch die Regelung 
RC300/GB172 sitzt.

Allerdings kann ich auf dem Bus nicht schreiben.

Bspw. bringt ein 'getversion' in der Konsole des collectord:7777 dann 
ein timeout:
```
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
IO: Sending bytes 0x88 0x10 00 0x60
ERRTIMEOUT
```

So etwas kam auch mal rein
```
IO: Got bytes 0xaa 0x55 0x19 0x8 00 0x2a 00 00 00 00 00 00 00 00 0x1 0xd 
0x1 0xd 0x80 00 00 0x80 00 0x80 00 0x80 00 00 0x22
MESSAGE[01.01.2016 17:56:33]: source 0x08, dest 0x00, type 0x2a, offset 
0, data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x0d 0x01 0x0d 0x80 
0x00 0x00 0x80 0x00 0x80 0x00
 0x80 0x00 0x00
DATA: Unhandled message received(source 0x08, type 0x2a).
IO: Got bytes 0xaa 0x55 0x17 0x8 00 0x34 00 0x3c 0x2 0x4a 0x2 0x4a 0x21 
00 0x1 0x3 00 00 0x2 0x63 00 00 0x5c 00 0x80 00 0x9e
MESSAGE[01.01.2016 17:56:34]: source 0x08, dest 0x00, type 0x34, offset 
0, data: 0x3c 0x02 0x4a 0x02 0x4a 0x21 0x00 0x01 0x03 0x00 0x00 0x02 
0x63 0x00 0x00 0x5c 0x00 0x80
 0x00
```


```

Scheitert es nun an der Pin-Zuordnung? Hardcoded ist es in ethersex ja 
nicht. USART0 habe ich unter
Protocols/EMS/UART 0
ausgewählt.


Vielen Dank im Voraus für eure Hilfe.

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Wie alt ist dein Ethersex-Checkout, und welches Repo verwendest du? Bis 
vor kurzem musste man im Pinning den TX-Pin für die Generierung der 
Break-Condition nochmal separat konfigurieren.

von Matthias F. (pullmoll)


Bewertung
0 lesenswert
nicht lesenswert
Es ist das Standard-Ethersex-Repo:

git:master

Den git-clone habe ich vor einer Woche gemacht.

von Denis L. (denis_l)


Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe EMS Gemeinde,

habe mir auch die Platine im freien Layout aufgebaut, und ebenfalls das 
Problem, das die EMS STATS auch leer sind, es ist aber ein 664p auf 
einem AVR NET IO verbaut.

Die Platine habe ich schon zwei mal kontrolliert.
Ich habe das fertige HEX file von der EMS Wiki Seite mit einem MKII und 
Atmel Studio 7 programmiert.

Anschliessen habe ich auch die Fuses kontrolliert.
Fuses: low=E7 high=DC ex=FF lock=FF.

Was mich auch etwas stuzig macht unter HTTP://x.x.x.x/adc.ht haben die 8 
Kanäle immer so um die 30 %.

Auch wenn ich über das Testcollektor JAVA Tool mal eine Uhrzeit sende 
Blinkt keine sende leuchte.

Hat noch jemand eine Idee, oder eine fertige Adapterplatine die getestet 
ist zum erweben.

Als Heizkessel ist hier ein LOGAMAX GB132 mit RC30 die auch 
Funktionsfähig ist.

Bytes total:3
Bytes good:0
Bytes dropped:0
Packets good:0
Packets bad:0
Packets 1byte:3 0
Packets ack:0 nack:0
Overflow:0
Max fill:1

: Bearbeitet durch User
von Peter W. (piet61)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,
habe mir jetzt (nach Aufsetzen eines Ubuntu Rechners) das Hexfile mit 
den richtigen Netzwerkeinstellungen selbst erstellt. Nun funktioniert 
die NetIO Platine wir erwartet.
Trotzdem komisch, dass die Netzwerkparameter nicht dauerhaft gespeichert 
werden :-(

Nun habe ich leider noch ein Problem bei der Installation der EMSTools 
auf dem Raspi.

Ich nutze einen Raspi2 Modell B mit Raspian Jessie.

Die Installation von libmysql++ funktioniert schon nicht. Ich habe die 
Meldung mal als Text File angehängt.
Ich habe hier im Forum einen Eintrag gefunden, dass ein '-dev' angehängt 
werden muss - also "sudo apt-get install libmysql++-dev" - das ist dann 
ohne Fehler durchgelaufen.

Nach der Installation der anderen Pakete, habe ich die Installation der 
EMS Tools mit "sudo dpkg --install ./ems-buderus_0-4.deb" gestartet.
Die Installation läuft bis zu einem bestimmten Punkt bei dem Compilieren 
des Collectors mit RAW support - da bricht er dann ab (siehe angehängte 
Datei).

Ich würde mich über Tips, wie ich das Problem lösen kann, sehr freuen.

Viele Grüße

piet

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Wer auch immer das deb-Package erstellt hat, muss sein Makefile 
aktualisieren. Da fehlt ein -DHAVE_MYSQL. Der erste Compilevorgang läuft 
wahrscheinlich mit meinem Makefile (und funktioniert deshalb), der 
zweite Compilevorgang benutzt wahrscheinlich ein eigenes Makefile.

von Peter W. (piet61)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,

vielen Dank für die Rückmeldung :-)
Das deb-Paket wurde von Lars_r48 erstellt. Was mich nur wundert ist, 
dass bisher offensichtlich sonst niemand das Problem hatte - oder kann 
es sein, dass es nur bei mir nicht funktioniert?

@Lars_r48
hättest Du Zeit und Lust, das deb-Package anzupassen? Ich würde mich 
über eine kurze Rückmeldung freuen, da ich ansonsten versuchen würde, 
die Komponenten "zu Fuß" zu installieren.

piet

von Lars R. (lars_r48)


Bewertung
0 lesenswert
nicht lesenswert
Ich glaube das ist so alt, da wird einiges nett mehr Funktionieren.
Ich sehe es mir heute Abend mal an, aber da ich es selbst nicht mehr 
nutzen kann wegen meiner Rc300 hatte ich es auch aus den Augen verloren.

von Lars R. (lars_r48)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für die Abhängigkeiten bitte selbst sorgen, bin da kein Profi drinne....

von Denis L. (denis_l)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der 
644p-20pu der richtige Processor.

low=E7 high=DC ex=FF lock=FF.

Des weiteren wenn ich mit der JAVA Collektor Software sende,
muss dann auf jeden fall die LED Blinken ????
Das tut sie auch nicht.

Danke für eure hilfe

: Bearbeitet durch User
von Matthias F. (pullmoll)


Bewertung
0 lesenswert
nicht lesenswert
Denis L. schrieb:
> mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der
> 644p-20pu der richtige Processor.

Der controller passt.
Erstelle das hexfile besser mal selbst aus ethersex'github

Ich habe auch noch das Problem,dass ich keine Daten senden kann. Empfang 
klappt aber.
Wahrscheinlich die selbst gebaute Platine...
Wenn da wer mal eine für mich übrig hat, wäre ich sehr froh...

von Peter W. (piet61)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

nach einigen Fehlschlägen und einigem Rumprobieren habe ich den 
"collectord" nun compiliert bekommen...
Und was soll ich sagen - ES FUNKTIONIERT (weitestgehend) :-)

Ein riesengroßes Dankeschön schonmal an Alle, die hier Fragen 
beantworten und Ihre Zeit und Ihr Wissen zur Verfügung stellen!!!

Leider gibt es noch ein paar Dinge, die nicht ganz rund laufen und daher 
habe ich noch einige Fragen.

Zunächst mal bekomme ich den "collectord" nicht als Service gestartet. 
Beim Versuch passiert folgendes:
sudo service ems-collector start
Job for ems-collector.service failed. See 'systemctl status ems-collector.service' and 'journalctl -xn' for details.

systemctl status ems-collector.service
● ems-collector.service - LSB: EMS collector daemon
   Loaded: loaded (/etc/init.d/ems-collector)
   Active: failed (Result: exit-code) since Mon 2016-01-11 18:37:05 CET; 27s ago
  Process: 5905 ExecStart=/etc/init.d/ems-collector start (code=exited, status=1/FAILURE)

"Zu Fuß" kann ich den "Collectord" problemlos starten und er empfängt 
auch Daten über den NetIO vom EMS Bus.

Die Dazugehörigen Konfigurationsdateien habe ich an diesen Post 
angehängt.
/etc/ems-collector.conf
/etc/init.d/ems-collector
/etc/Default/ems-collector

Das "collectord" Binary liegt im Verzeichnig /usr/local/sbin

Vielleicht kann ja jemand helfen...

Vielen Dank und viele Grüße

piet

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Was sagt denn journalctl -xn? Ansonsten fällt mir außer der Tatsache, 
dass die meisten Parameter (-u, -p, -r, -C, -D) sowohl in OPTIONS als 
auch in der Konfigurationsdatei enthalten sind (wozu?) erst mal nicht 
viel auf.

von Peter W. (piet61)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,
vielen Dank für die schnelle Antwort :-)
journalctl -xn sagt:
 $ sudo journalctl -xn
-- Logs begin at Mon 2016-01-11 20:18:37 CET, end at Mon 2016-01-11 21:11:24 CET. --
Jan 11 21:10:56 raspi2 ems-collector[2358]: -u [ --db-user ] arg  Database user name
Jan 11 21:10:56 raspi2 ems-collector[2358]: -p [ --db-pass ] arg  Database password
Jan 11 21:10:56 raspi2 ems-collector[2358]: TCP options:
Jan 11 21:10:56 raspi2 ems-collector[2358]: -C [ --command-port ] arg TCP port for remote command interface (0 to
Jan 11 21:10:56 raspi2 ems-collector[2358]: disable)
Jan 11 21:10:56 raspi2 ems-collector[2358]: -D [ --data-port ] arg    TCP port for broadcasting live sensor data (0 to
Jan 11 21:10:56 raspi2 ems-collector[2358]: disable)
Jan 11 21:10:56 raspi2 ems-collector[2358]: failed!

Stören die doppelt eingetragenen Parameter? Welche Parameterdatei sollte 
man nutzen?

piet

von Peter W. (piet61)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

so, habe nun noch Moosys WEB Interface installiert. Super Darstellung 
der verschiedenen Werte - echt klasse!

Das Problem mit dem collectord als Service besteht immer noch, habe ich 
aber erstmal zurückgestellt...

Meine Heizungsanlage ist eine GB132 mit RC30 Controller und 2 
Heizkreisen (HK1 Heizkörper, HK2 Fußboden) und Warmwasserboiler.

Ich habe gelesen, dass Moosys WEB Interface nur für einen Heizkreis 
gedacht ist (es werden ja auch nur die Werte von HK1 angezeigt).
Hat schonmal jemand die Anpassungen für 2 Heizkreise vorgenommen oder 
kann mir jemand einen Tip geben, worauf dabei zu achten ist (kenne mich 
leider mit PHP und AJAX nicht aus)?

Leider funktionieren nicht alle Anzeigen im WEB Interface fehlerfrei.

- Keine Temperaturanzeige beim Livestatus (Heizkreis)
- Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B. 
fehlen die Temperaturwerte)
- Heizkurve wird nicht angezeigt. Das WEB Interface sagt, die Anlage sei 
raumtemperaturgeführt - ich habe im Servicemenü vom RC30 nochmal 
kontrolliert, dort ist für beide Heizkreise "keine" Fernbedienung 
eingetragen.
- Unter "erweiterte Einstellungen" werden nicht alle Änderungen in das 
System übernommen - z.B. "Nachtabsenkung abbrechen unter". Dagegen 
werden andere Parameter (z.B. Nachlaufzeit der Kesselpumpe) sehr wohl 
übernommen. Hier wird übrigens auch 'raumtemperaturgeführt' angezeigt, 
eine Änderung wird aber nicht übernommen.
- Bei der Statistk fehlen immer die Werte in der Letzten Tabelle und die 
Graphen werden nicht generiert


Im Anhang mal einige Screenshots von den Anzeigen im WEB Interface.

Viele Grüße

piet

von Danny B. (maniac103)


Bewertung
0 lesenswert
nicht lesenswert
Peter W. schrieb:
> Hallo Danny,
> vielen Dank für die schnelle Antwort :-)
> journalctl -xn sagt: $ sudo journalctl -xn
> -- Logs begin at Mon 2016-01-11 20:18:37 CET, end at Mon 2016-01-11
> 21:11:24 CET. --
> Jan 11 21:10:56 raspi2 ems-collector[2358]: -u [ --db-user ] arg
> Database user name
> Jan 11 21:10:56 raspi2 ems-collector[2358]: -p [ --db-pass ] arg
> Database password
> Jan 11 21:10:56 raspi2 ems-collector[2358]: TCP options:
> Jan 11 21:10:56 raspi2 ems-collector[2358]: -C [ --command-port ] arg
> TCP port for remote command interface (0 to
> Jan 11 21:10:56 raspi2 ems-collector[2358]: disable)
> Jan 11 21:10:56 raspi2 ems-collector[2358]: -D [ --data-port ] arg
> TCP port for broadcasting live sensor data (0 to
> Jan 11 21:10:56 raspi2 ems-collector[2358]: disable)
> Jan 11 21:10:56 raspi2 ems-collector[2358]: failed!
> Stören die doppelt eingetragenen Parameter?

Die Ausgabe deutet schon daraufhin.

> Welche Parameterdatei sollte man nutzen?

Das ist prinzipiell egal, solange man jeden Parameter nur 1x angibt. Ich 
persönlich habe alles in ems-collector.conf, d.h. OPTIONS ist bei mir 
leer.

> Ich habe gelesen, dass Moosys WEB Interface nur für einen Heizkreis
> gedacht ist (es werden ja auch nur die Werte von HK1 angezeigt).
> Hat schonmal jemand die Anpassungen für 2 Heizkreise vorgenommen oder

Nicht dass ich wüsste. Ich würde aber auch Interesse daran anmelden.

> kann mir jemand einen Tip geben, worauf dabei zu achten ist (kenne mich
> leider mit PHP und AJAX nicht aus)?

Das sind dann leider keine guten Startvoraussetzungen :(

> Leider funktionieren nicht alle Anzeigen im WEB Interface fehlerfrei.
>
> - Keine Temperaturanzeige beim Livestatus (Heizkreis)

Das hängt an den fehlenden Werten (wird aus 'hk1 daymode', 'hk1 
daytemperature' und 'hk1 nighttemperature' bestimmt). Siehe unten.

> - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B.
> fehlen die Temperaturwerte)

Das ist teilweise normal und teilweise komisch. Speziell die 
Temperaturwerte sollten auf alle Fälle da sein. Probier mal, dich mit 
Telnet auf Port 7777 zu verbinden und da das Kommando 'cache fetch hk1' 
aufzurufen. Sind dort daymode, daytemperature und nighttemperature 
vorhanden? Wenn ja, gucke ich nochmal in Moosy's Code nach, wie er das 
verarbeitet. Wenn nein, mache mal bitte folgendes:
- führe den Collector mit den Parametern '-d message' und '-f' aus
- verbinde dich zu Port 7777 (auf einem anderen Terminal)
- 'hk1 requestdata'
- wenn das fertig ist, poste bitte die Debug-Ausgaben des Collectors

> - Heizkurve wird nicht angezeigt. Das WEB Interface sagt, die Anlage sei
> raumtemperaturgeführt - ich habe im Servicemenü vom RC30 nochmal
> kontrolliert, dort ist für beide Heizkreise "keine" Fernbedienung
> eingetragen.

Trag mal 'rc-type = rc30' in die Config ein, dann wird's wahrscheinlich 
gehen. Ich sollte mal eine Warnung hinzufügen, wenn dieser Wert nicht 
gesetzt ist.

> - Unter "erweiterte Einstellungen" werden nicht alle Änderungen in das
> System übernommen - z.B. "Nachtabsenkung abbrechen unter". Dagegen
> werden andere Parameter (z.B. Nachlaufzeit der Kesselpumpe) sehr wohl
> übernommen. Hier wird übrigens auch 'raumtemperaturgeführt' angezeigt,
> eine Änderung wird aber nicht übernommen.

Funktioniert denn z.B. ein 'hk1 reducedmodethreshold 5' auf Port 7777?

> - Bei der Statistk fehlen immer die Werte in der Letzten Tabelle und die
> Graphen werden nicht generiert

Wenn die Raumtemperatur nicht gemessen werden kann, kann auch keine 
Statistik darüber geführt werden ;-)
Die Graphen habe ich früher über einen Cronjob alle paar Minuten 
erzeugt; ich bin mir allerdings nicht sicher, ob das bei Moosy noch 
genauso ist.

von Danny B. (maniac103)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter W. schrieb:
> - Einige komische oder gar keine Werte in der Rohdatenanzeige (z.B.
> fehlen die Temperaturwerte)

Probier mal deine emsdetail.ajax mit der angehängten Version zu 
ersetzen.

von Peter W. (piet61)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Danny,
habe in der /etc/ems-collector.conf den Parameter "rc-type = rc30" 
ergänzt und in der /etc/default/ems-collector die Zeile OPTIONS="...." 
auskommentiert.

Leider immer noch der gleiche Fehler beim Versuch, den collectord als 
Service zu starten...

Habe mal Deine "emsdetail.ajax" genommen - und siehe da, die Werte sind 
nun vorhanden...

Ich habe den collectord nun mal mit dem Parameter "-R rc30" gestartet 
und nun erkennt er auch, dass das System außentemperaturgeführt 
arbeitet. Allerdings wird die Heizkurve immer noch nicht gezeichnet :-( 
- ebenso wie die Graphen auf der Statistikseite. Wie lässt ma die denn 
per Cron Job zeichnen?

Der Befehl "hk1 reducemodethreshold 5" wird im Telnet Fenster akzeptiert
telnet localhost 7777
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hk1 reducedmodethreshold 5
OK

...aber welchem Wert enspricht dies auf Moosys Webinterface - dem 
"Nachts reduzierter Betrieb unter"? Falls ja, dann wird der Wert nicht 
übernommen, denn in der Weseite (nach einem Refresh) steht dort wieder 0 
Grad.

Wenn ich z.B. den Wert "Nachtabsenkung abbrechen unter" auf der Webseite 
auf -5 setze, dann steht unten auf der Seite
Wert 'absquit' gesetzt auf '-5'.

Der Wert im Browser auf der Seite "Einstellungen" 'überlebt' auch einen 
Reload der Seite - allerdings nicht den Wechsel auf z.B. die Livestatus 
Seite und zurück.

Die Heizkreistemperatur auf der Livestatus Seite wird auch trotz des 
RC30 Parameters nicht angezeigt - möglicherweise hängt das ja mit den 2 
Heizkreisen zusammen...

Habe dann noch den collectord mit den von Dir genannten Parametern 
gestartet:
sudo ./collectord -R rc30 -C 7777 -D 7778 -u ems -p buderus -r 60 -d message -f tcp:192.168.1.60:7950 >/tmp/collectord.log

... und in einem anderen Fenster ein Telnet gestartet und den Befehl 
'hk1 requestdata' eingegeben - erstaunlicherweise bekomme ich in dem 
Telnet Fenster dazu keinen Output...
telnet localhost 7777
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hk1 requestdata
OK

Das Logfile vom collectord enhält nicht viel Informationen - ich habe es 
trotzdem mal angehängt - vielleicht sind es ja die entscheidenden Infos 
;-)

Viele Grüße

piet

von Peter W. (piet61)


Bewertung
0 lesenswert
nicht lesenswert
Habe den Fehler mit den Graphen gefunden :-)

In der Datei /emsinclude/config.py muss es heißen
mysql_socket_path = "/var/run/mysqld/mysqld.sock"

... dann klappt es auch mit den Grafiken :-)

von Denis L. (denis_l)


Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Denis L. schrieb:
>> mal eine kurze frage da sich bei mir noch irgendwioe gar nix tut ist der
>> 644p-20pu der richtige Processor.
>
> Der controller passt.
> Erstelle das hexfile besser mal selbst aus ethersex'github
>
> Ich habe auch noch das Problem,dass ich keine Daten senden kann. Empfang
> klappt aber.
> Wahrscheinlich die selbst gebaute Platine...
> Wenn da wer mal eine für mich übrig hat, wäre ich sehr froh...

Ja ich empfange mittlerweile auch endlich mal Daten mit der 
Lochrasterplatine, hab mir eine Platine nun Ätzen lassen.

Kannst Du mir ein Hexfile erstellen, hier will die aktuelle Github mir 
keins rauswerfen, bekomme immer Fehlermeldungen.

IP 192.168.2.41
SUB 255.255.255.0
GW 192.168.2.1

Das wäre super von euch.

Liebe Grüsse Denis

von Matthias F. (pullmoll)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zeig mal die Logs her, was da beim Kompilieren schief geht.

Ich habe im Anhang trotzdem mal ein hex-file für 644p@16MHz mit EMS auf 
USART1 gebaut. Hardware Pollin-AVR.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.