Läuft: Heizung mit eBus-Schnittstelle

[yuhu]

@heikoh81

Welche Befehle hast du den für Ident 47000 schon identifiziert?

[amunra]

Hallo Roland,

bei mir laufen u.a folgende broadcast messages:

Code Auswählen Erweitern

1008b511010189
1008b51101028a

Diese habe ich versucht in die broadcast.csv abzulegen und bekomme beim "reload" eine Meldung "ERR: duplicate entry" (Bei eigenen Templates bekomme ich auch diese Meldung).
Die Einträge sehen so aus:

Code Auswählen Erweitern

b,broadcastStatus1,Status1,VL/RL/AussenT/VLWW/RLWW/Status,,08,B511,01,01,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
b,broadcastStatus2,Status2,OP Data from CI to Burner CU,,08,B511,01,02,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,


Hier wird scheinbar nur bis zu der Datenlänge geprüft?
Wie könnten die Einträge aussehen?
Danke.

P.S. Ein Fullscan hat heute funktioniert und liefert bei mir das:

Code Auswählen Erweitern

08;Joh. Vaillant GmbH & Co.;BAI00;0516;7401
15;Joh. Vaillant GmbH & Co.;43000;0215;2002
26;Joh. Vaillant GmbH & Co.;43000;0215;2002

S/N wird wohl nicht mehr ermittelt bzw. ausgewertet.

EDIT:

ok, ich habe es wie folgt geändert (Source address hinzugefügt) und nun funktioniert es (gut, schön ist es nicht):

Code Auswählen Erweitern

b,,Status,VL/RL/AussenT/VLWW/RLWW/Status,,08,B511,01,01,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
b,,Status2,OP Data from CI to Burner CU,10,08,B511,01,02,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

EDIT2:

Zu früh gefreut, Status2 nimmt die Status Werte an:

OK

Code Auswählen Erweitern

update MS cmd: 1008b511010189 / 097a5c90014e4c0100ffb1
[upd event] update broadcast Status2: 61.0;46.0;1.562;39.0;38.0;1

nicht OK

Code Auswählen Erweitern

[upd trace] update MS cmd: 1008b51101028a / 05033c96507884
         [upd event] unknown MS cmd: 1008b51101028a / 05033c96507884


[Prof. Dr. Peter Henning]

Nein, das sind keine Befehle an die CalorMatic, sondern allesamt zyklische Statusabfragen der CalorMatic an die Therme (10->08).

Es sei ganz ernsthaft (Lebensgefahr!) davor gewarnt, die Therme mit aktiven Steuerungsbefehlen an der CalorMatic vorbei steuern zu wollen. Aktive Steuerungsbefehle dürfen nur an die CalorMatic abgesetzt werden. Bisher haben wir aber noch nicht einmal versucht, sie zu steuern - die ganzen ausgetesteten Befehle sind lediglich Statusabfragen
(
@yuhu: Insofern ist es mehrdeutig, statt des ebusd-Kommando "hex" jetzt "write -h" zu verwenden
)

Also folgende Vorgehensweise: Wir testen jetzt mal den lesenden Zugriff auf die internen Register der CalorMatic. Mit

ebusctl write -h 15B509030D0000

wird das erste Register abgefragt, mit der Endung 0100 das 2. etc.. Bitte mal fortsetzen für die ersten 16 Register, also bis 15B509030D0F00

Die Antwort sollte jeweils aus mindestens 4 Byte bestehen.

Desweiteren kann man versuchen, das interne Heizkreismodul der CalorMatic lesend anzusprechen (jeweis als ebusctl write -h):

Registerabfragen 26B509030D0000 bis 0F00
Statusabfragen 26B5040100 bis 0F

LG

pah

[yuhu]

Es sei ganz ernsthaft (Lebensgefahr!) davor gewarnt, die Therme mit aktiven Steuerungsbefehlen an der CalorMatic vorbei steuern zu wollen. Aktive Steuerungsbefehle dürfen nur an die CalorMatic abgesetzt werden.

Ich kann dem nur beipflichten.

(
@yuhu: Insofern ist es mehrdeutig, statt des ebusd-Kommando "hex" jetzt "write -h" zu verwenden
)

Jein, mit "write -h" wird der angegeben Hex-String (so wie er ist)  auf den Bus geschrieben. Natürlich könnte man auch eine "read -h" implementieren. Ein write trifft es aber besser.

[Prof. Dr. Peter Henning]

@yuhu: Nein, das meine ich anders. Aus Sicherheitsgründen sollte ein Benutzer in der Konfigurationsdatei (nicht in der CSV, sondern auf der Kommandozeile bzw. in der Einstellungsdatei) explizit angeben müssen, dass er Schreibbefehle absetzen will. Wenn man es ganz komfortabel haben will, könnte man im ebusd all die Kommandos, die tatsächliche Steuerbefehle absetzen, von einer weiteren expliziten Einstellung abhängig machen. Für Vaillant wären das in der Regel die B509030E und die B505-Befehle - aber erstens weiß ich (noch) nicht, ob es da noch weitere verändernde Befehle gibt, und zweitens benutzen natürlich noch andere Hersteller den EBUS.

LG

pah

P.S.: Ich habe mit Entsetzen festgestellt, dass in der allerneuesten trunk-Version vom ebusd meine Konfigurationsdatei nicht mehr das tut, was sie soll 

Edit: Ist auch kein Wunder, man sollte keine global changes machen.... mein Fehler.

[amunra]

Hallo,

danke für die Informationen.
Dann habe ich broadcast Befehle, die offensichtlich auf den Bus schreiben (ein Senden an alle bzw. in die Runde), mit "auf dem Bus mitlauschen und die Messages abgreifen", falsch interpretiert.
Meine Idee war die Daten, die sowieso schon von den Teilnehmern über den Bus geschickt werden, zu verwenden. Aktiv abfragen ist sicher sinnvoller.

Derzeit beschäftige ich mich "nur" mit den bekannten Get Befehlen, an die Set Befehle möchte ich im Moment noch nicht dran.
VG Arthur

P.S: @pah es werden sicher viele Daten die Abgegriffen werden können. Wie ist deine bisherige Erfahrung mit ECMD und den classdefs (es sind sicher schon ein paar Hundert Zeilen Code oder)?. Ich denke, dass es schnell unübersichtlich wird? Siehst du Optimierungspotenziale (Verwendung der CSV als Template, etc.) in der bisherigen Implementierung? Danke.

[Prof. Dr. Peter Henning]

Die classdefs sind deshalb wichtig, weil sie bestimmen, was in FHEM als "get" und "set" angezeigt wird (jedenfalls, so lange es noch kein Vaillant-Modul gibt  ).

Der eigentliche Code steht bei mir in der Datei 99_myUtils.pm, das ist viel flexibler. Neben manuell auszuführenden get-Befehlen (z.B.  get TimerProgMonday) sind aber nur zwei wichtig: get mode (zyklisch von FHEM abgefragt einmal morgens kurz nach Mitternacht, holt die wesentlichen Einstellungsparameter; jeweils für Heizung, Warmwasser, Solar) und get state (zyklisch alle 60 Sekunden, fragt den aktuellen Betriebszustand ab).

LG

pah

[heikoh81]

@pah:

Es fällt mir etwas schwer, dies zu glauben - denn das Steuergerät wird entweder komplett die Antwort verweigern, oder zusammen mit dem Datenwert sowohl die Anzahl der Datenbytes als auch einen CRC-Code liefern.

Also ich poste hier keine falschen Rückmeldungen.
Ich poste genau das, was ich erhalte. Da habe ich auch viel zu wenig Ahnung um hier irgendjemand in die Irre führen zu wollen und auch zu viel Respekt von der vielen Mühe aller Teilnehmer, die in der Entwicklung und Entschlüsselung dieses ebusd liegt!!!!

Also bitte mal mitteilen, (bei diesen beiden Kommandos), welche _Rohdaten_ auf dem Bus zu lesen sind (ebusd evtl. im Vordergrund starten).

Ich habe also ebusd im Vordergrund gestartet mit: ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
Dann 2. Telnet-Verbindung zum Raspberry aufgebaut und dieses Kommando abgesetzt: ebusctl write -h 15B5040101
Ergebnis: (ich habe ein paar Zeilen davor und danach stehen lassen)

Code Auswählen Erweitern


root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
2014-12-30 14:36:50.979 [bas event] ebusd started
2014-12-30 14:36:50.981 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-30 14:36:50.995 [bas trace] read templates
2014-12-30 14:36:51.061 [bas trace] read config files
2014-12-30 14:36:51.062 [bas event] message DB: 117
2014-12-30 14:36:51.063 [bas event] updates DB: 15
2014-12-30 14:36:51.064 [bas event] polling DB: 0
2014-12-30 14:36:53.427 [upd trace] update MS cmd: 1008b511010189 / 096d601001ff490100ff97
2014-12-30 14:36:53.429 [upd event] update MS StatusHC: 54.5;48.0;16;1;1
2014-12-30 14:36:55.279 [upd trace] update MS cmd: 1008b50401003d / 0a035736143012021410019a
2014-12-30 14:36:55.538 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:36:55.772 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-30 14:37:12.941 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:37:13.217 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:37:13.218 [upd event] update MS SetBoiler: 1;77.0
2014-12-30 14:37:13.659 [upd trace] update MS cmd: 1008b511010189 / 096d601001ff490100ff97
2014-12-30 14:37:13.661 [upd event] update MS StatusHC: 54.5;48.0;16;1;1
2014-12-30 14:37:15.603 [upd trace] update BC cmd: 10feb51603011001ef
2014-12-30 14:37:15.605 [upd event] update BC OutsideTempBC: 1.062
2014-12-30 14:37:19.746 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:37:19.748 [upd event] update MS SetBoiler: 1;77.0
2014-12-30 14:37:20.053 [net trace] [00001] connection opened 127.0.0.1
2014-12-30 14:37:20.056 [bas event] >>> write -h 15B5040101
2014-12-30 14:37:20.057 [bas event] write hex cmd: ff15b5040101d6
2014-12-30 14:37:20.165 [bus event] read res: 0000
2014-12-30 14:37:20.167 [bas event] <<< 0000
2014-12-30 14:37:20.175 [net trace] [00001] connection closed
2014-12-30 14:37:23.728 [upd trace] update MS cmd: 1008b511010189 / 096d601001ff490100ff97
2014-12-30 14:37:23.730 [upd event] update MS StatusHC: 54.5;48.0;16;1;1
2014-12-30 14:37:25.837 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:37:29.815 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:37:29.817 [upd event] update MS SetBoiler: 1;77.0
^C2014-12-30 14:37:30.565 [bas event] SIGINT received
2014-12-30 14:37:30.682 [bas event] ebusd stopped

Das Abschießen von ebusd geschieht wohl durch STRG + C, wenn ich den Code hier fürs Forum kopiere - ebusd vom 26.12.2014 läuft extrem stabil seit mehreren Tagen 24/7, trotz minütlicher Telnet-Abfragen über FHEM.

Dasselbe dann nochmal für Befehl: ebusctl write -h 26B5040101

Code Auswählen Erweitern


root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
2014-12-30 14:42:25.582 [bas event] ebusd started
2014-12-30 14:42:25.583 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-30 14:42:25.596 [bas trace] read templates
2014-12-30 14:42:25.651 [bas trace] read config files
2014-12-30 14:42:25.652 [bas event] message DB: 117
2014-12-30 14:42:25.653 [bas event] updates DB: 15
2014-12-30 14:42:25.654 [bas event] polling DB: 0
2014-12-30 14:42:26.559 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:42:27.584 [net trace] [00001] connection opened 127.0.0.1
2014-12-30 14:42:27.587 [bas event] >>> write -h 26B5040101
2014-12-30 14:42:27.587 [bas event] write hex cmd: ff26b50401017c
2014-12-30 14:42:27.668 [bus event] read res: 0000
2014-12-30 14:42:27.669 [bas event] <<< 0000
2014-12-30 14:42:27.677 [net trace] [00001] connection closed
2014-12-30 14:42:28.557 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:42:28.559 [upd event] update MS SetBoiler: 1;77.0
^C2014-12-30 14:42:32.323 [bas event] SIGINT received
2014-12-30 14:42:32.441 [bas event] ebusd stopped


Erfolgsversprechender sind die neuen von pah genannten writes - doch was bedeuten die Antworten?

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 15B509030D0000
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0200
01019a

root@fhemALT:~# ebusctl write -h 15B509030D0300
0712310e011e0c0e40

root@fhemALT:~# ebusctl write -h 15B509030D0400
01019a

root@fhemALT:~# ebusctl write -h 15B509030D0500
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0600
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0700
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0800
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0900
010299

root@fhemALT:~# ebusctl write -h 15B509030D00A0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00B0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00C0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00D0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00E0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00F0
036e01000a


@yuhu:

@heikoh81
Welche Befehle hast du den für Ident 47000 schon identifiziert?

Ich verwende die von pah bereitgestellten Dateien - selbst konnte ich leider noch nichts entschlüsseln
http://forum.fhem.de/index.php/topic,29737.msg235842.html#msg235842

Wie kann ich jetzt weitermachen?

Viele Grüße,
Heiko

[heikoh81]

Hier liefere ich noch die fehlenden Abfragen nach.

ebusctl write -h 26B509030D0000 bis 0F00 (Registerabfragen):

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 26B509030D0000
036f01001c
root@fhemALT:~# ebusctl write -h 26B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0200
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0300
076363636363636310
root@fhemALT:~# ebusctl write -h 26B509030D0400
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0500
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0600
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0700
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0800
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0900
010299
root@fhemALT:~# ebusctl write -h 26B509030D0A00
0200002c
root@fhemALT:~# ebusctl write -h 26B509030D0B00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0C00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0D00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0E00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0F00
01009b


ebusctl write -h 26B5040100 bis 0F (Statusabfragen):

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 26B5040100
0000
root@fhemALT:~# ebusctl write -h 26B5040101
0000
root@fhemALT:~# ebusctl write -h 26B5040102
0000
root@fhemALT:~# ebusctl write -h 26B5040103
0000
root@fhemALT:~# ebusctl write -h 26B5040104
0000
root@fhemALT:~# ebusctl write -h 26B5040105
0000
root@fhemALT:~# ebusctl write -h 26B5040106
0000
root@fhemALT:~# ebusctl write -h 26B5040107
0000
root@fhemALT:~# ebusctl write -h 26B5040108
0000
root@fhemALT:~# ebusctl write -h 26B5040109
0000
root@fhemALT:~# ebusctl write -h 26B504010A
0000
root@fhemALT:~# ebusctl write -h 26B504010B
0000
root@fhemALT:~# ebusctl write -h 26B504010C
0000
root@fhemALT:~# ebusctl write -h 26B504010D
0000
root@fhemALT:~# ebusctl write -h 26B504010E
0000
root@fhemALT:~# ebusctl write -h 26B504010F
0000


Warum ist es lebensgefährlich, wenn man an der Calormatic vorbeisteuert?
Was lebensgefährliches möchte ich nicht tun!
Die Heizung müsste sich doch egal welche Befehle ich ihr absetze immer im Rahmen ihrer physikalischen Grenzen (Maximal-Temperaturen etc.) bewegen, oder?

Viele Grüße,
Heiko

[Prof. Dr. Peter Henning]

root@fhemALT:~# ebusctl write -h 15B509030D0000
036e01000a

=====> 03= Länge in Bytes 6e 01 = 016e = Temperaturwert (Datentyp temp.) Könnte die Außentemperatur sein, irgendetwas um 1,5 Grad Celsius 0a= CRC

root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b

=====> 01 = Länge, Datenwert 0, 9b=CRC

root@fhemALT:~# ebusctl write -h 15B509030D0200
01019a

=====> 01 = Länge, Datenwert 1, 9a=CRC

root@fhemALT:~# ebusctl write -h 15B509030D0300
0712310e011e0c0e40

=====> 7 Bytes. Ich rate mal: 12h = 18 = Absenktemperatur 31h = 49 ?? Idealerweise die Parameter der Heizung verändern, und dieses register noch mal abfragen

root@fhemALT:~# ebusctl write -h 15B509030D0400
01019a

root@fhemALT:~# ebusctl write -h 15B509030D0500
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0600
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0700
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0800
01009b

root@fhemALT:~# ebusctl write -h 15B509030D0900
010299

=====> AAAH: 1 Byte, dann ein Datenwert 02, dann CRC. Ist ein Statuscode. Wie verändert sich der, wenn man auf "Nacht" umschaltet ?

root@fhemALT:~# ebusctl write -h 15B509030D00A0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00B0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00C0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00D0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00E0
036e01000a

root@fhemALT:~# ebusctl write -h 15B509030D00F0
036e01000a

Code: [Auswählen]

root@fhemALT:~# ebusctl write -h 26B509030D0000
036f01001c

=====>  3 bytes Könnte Temperatur + Sensorstatus sein

etc.

Mach doch bitte mal eine ordentliche OpenOffice- oder Excel-Tabelle

LG

pah

[heikoh81]

Anbei die Befehle nochmals ausgeführt, Betriebsart Auto, Außentemperatur 1,06°C, Rücklauf 49°C.

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0300
072a0d11011e0c0ec4
root@fhemALT:~#  ebusctl write -h 15B509030D0900
010299


Betriebsart Nacht:

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 15B509030D0900
01009b


Update: Außentemp: 1,06 °C, Rücklauf: 37,50°C

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0300
076363636363636310


Und nach Umschalten auf Betriebsart: "Systemaus (Frostschutz Aktiv)":

Code Auswählen Erweitern


root@fhemALT:~# ebusctl write -h 15B509030D0900
01009b


Die Antworten für "Nacht" und "Systemaus" sind gleich.
Vielleicht ist das der Brennerstatus = Aus?

Könnte man daraus jetzt schon einen set-Befehl ableiten?

[Prof. Dr. Peter Henning]

Aber ja. Versuch mal, das Register 0900 von außen zu beschreiben (Befehl ist 0E statt 0D für lesen)

15B509040E090000

Der könnte dann von "auto" auf "nacht" umschalten (keine Garantie - vielleicht zündet das auch die pannensichere Selbstvernichtung  )

Und mach von den erfolgreich gelesenen Werten mal eine Tabelle.

LG

pah

[heikoh81]

Also das funktioniert leider nicht.
Ich habe sowohl 15B509040E090000 als auch 15B509040E0900 probiert, weil das Kommando ja 2 Stellen länger war als bisher.
Output im ebusd-Vordergrund siehe unten.

Code Auswählen Erweitern


2014-12-30 17:42:07.588 [net trace] [00014] connection opened 127.0.0.1
2014-12-30 17:42:07.591 [bas event] >>> write -h 15B509040E090000
2014-12-30 17:42:07.593 [bas event] write hex cmd: ff15b509040e09000056
2014-12-30 17:42:07.687 [bus event] read res: 0000
2014-12-30 17:42:07.690 [bas event] <<< 0000
2014-12-30 17:42:07.697 [net trace] [00014] connection closed
2014-12-30 17:42:10.516 [upd trace] update MS cmd: 1008b511010189 / 094a4a1001ff450000ffd3
2014-12-30 17:42:10.518 [upd event] update MS StatusHC: 37.0;37.0;16;1;0
2014-12-30 17:42:14.471 [net trace] [00015] connection opened 127.0.0.1
2014-12-30 17:42:14.474 [bas event] >>> write -h 15B509040E0900
2014-12-30 17:42:14.474 [bas event] write hex cmd: ff15b509040e090030
2014-12-30 17:42:14.565 [bus error] ERR: read timeout, retry send
2014-12-30 17:42:15.132 [bus error] ERR: read timeout, retry send
2014-12-30 17:42:15.699 [bus error] ERR: read timeout, retry send
2014-12-30 17:42:16.268 [bus error] ERR: read timeout,
2014-12-30 17:42:16.268 [bas error] write hex: ERR: read timeout
2014-12-30 17:42:16.268 [bas event] <<< ERR: read timeout
2014-12-30 17:42:16.276 [net trace] [00015] connection closed


Übrigens ist mein FHEM sofort wieder abgeschmiert, nachdem ich mit STRG + C die Werte aus putty kopiert und damit ebusd beendet habe.
Auch nach 4 Minuten bei 100% hat er sich nicht wieder gefangen, obwohl ebusd zwischenzeitlich wieder lief auf dem anderen Raspi.
Soll ich das mal in die Modul-Gruppe posten? Weil es hat eigentlich nix mit diesem Thread zu tun sondern muss an ECMD liegen?

Code Auswählen Erweitern

014.12.30 17:42:32 1: 192.168.178.239:8888 disconnected, waiting to reappear (EBUS)
2014.12.30 17:42:32 1: 192.168.178.239:8888 reappeared (EBUS)
2014.12.30 17:46:39 1: Including fhem.cfg

[heikoh81]

PN an Boris ist raus. Habe das Problem nur ich?
Hab ihm geschrieben dass er gerne auch hier für alle Antworten kann.



Umschalten habe ich nur per Telnet auf dem ebusd-Raspi gemacht.
In FHEM werden bisher nur Werte gelesen und angezeigt (so habe ich die Abstürze bemerkt).

[Dr. Boris Neubert]

Hallo, poste mal Logs vom abstürzenden FHEM mit verbose 5 und logTraffic. Viele Grüße Boris