Weishaupt WTC am eBus mit ebusd

Begonnen von J0EK3R, 19 November 2016, 13:51:45

Vorheriges Thema - Nächstes Thema

mcmuller

@john30 : OK, wo hast Du diese Info her? Ich habe über den TEM-Dongle fast nichts im Netz gefunden. "Opentherm" höre ich gerade zum ersten Mal  ::)

john30

Zitat von: mcmuller am 10 Dezember 2016, 09:02:05
@john30 : OK, wo hast Du diese Info her? Ich habe über den TEM-Dongle fast nichts im Netz gefunden. "Opentherm" höre ich gerade zum ersten Mal  ::)
nur ein bisschen gegoogelt...
author of ebusd

mcmuller

@john30 : Guten Morgen! Hast Du mal eine Quelle? Opentherm ist lt. Wikipedia ja ein ganz anderes Protokoll als ebus. Der TEM ZIF 280 ist aber definitiv ein ebus-Gerät. Steht sowohl auf der Verpackung als auch im zugehörigen Servicetool als auch an den Klemmen der Steuerung (TEM an einer Hautec-WP) mit der ich gerade teste.

john30

Zitat von: J0K3r am 08 Dezember 2016, 18:20:36
https://github.com/J0EK3R/ebusd-configuration-weishaupt
Jetzt muss ich die Konfigurationsdateien nur noch "in Form" bringen! ;)
Hierzu mal ein erster Tipp:

Wann immer Du einen Datentyp mehr als 1x in einem CSV verwendest, würde ich sofort dafür ein Template anlegen, das spart unheimlich Schreibarbeit.
Beispiel dafür: UIN,10 als Temperatur
Das würde ich gleich mal wie folgt in die _templates.csv packen:
temp10:temp,UCH,10,°C,Temperatur
author of ebusd

john30

Zitat von: mcmuller am 10 Dezember 2016, 09:09:04
@john30 : Guten Morgen! Hast Du mal eine Quelle? Opentherm ist lt. Wikipedia ja ein ganz anderes Protokoll als ebus. Der TEM ZIF 280 ist aber definitiv ein ebus-Gerät. Steht sowohl auf der Verpackung als auch im zugehörigen Servicetool als auch an den Klemmen der Steuerung (TEM an einer Hautec-WP) mit der ich gerade teste.
Oh, bin wohl auf dem 250er Interface gelandet, und das ist mit Mikrocontroller und Opentherm angegeben.
Beide sind auf der einen Seite mit eBUS verbunden, also das heißt erst mal noch nichts :-)
Beim 280er gibt es noch eine kleine Chance, dass das funktioniert. Lass Dir mal den raw Output ausgeben. Wenn da keine "<aa" im Log auftauchen, dann macht das Interface mehr als nur 1:1 durchreichen. Oder der Bus ist passiv, d.h. mit dem Interface musst Du den Sync generieren (--generatesyn an ebusd Aufruf übergeben)
author of ebusd

mcmuller

@John OK, kann ich dann erst nächste Woche testen - jetzt geht's in Kurzurlaub :-)

john30

Zitat von: mcmuller am 10 Dezember 2016, 09:28:36
@John OK, kann ich dann erst nächste Woche testen - jetzt geht's in Kurzurlaub :-)
sehr vernünftig:-) Gute Erholung!
author of ebusd

J0EK3R

Hallo John, der Anfang ist gemacht...

...ich habe die 35.csv auf Deinen Vorschlag mit temp10 umgestellt und etwas aufgeräumt.  :D

Wie soll ich denn eigenlich die Hex-Werte der Adressen schreiben, in Anführungszeichen oder nicht?  :-[

Und es gibt noch viel zu tun! Ich würde mir gerne die verschiedenen Programme vornehmen.
Hast Du einen Tipp für den Datentyp "Uhrzeit in Viertelstunden"?
Jeweils ein Byte für die Startzeit und die Endzeit. Lesen und schreiben kann man die beiden Werte nur zusammen (als Int16).


# Parameter Anwender 161 - Zirkulationsprogramm Montag
# Wert * 15 Minuten
# 255 (0xFF) -> Off
#   1 (0x01) -> 00:15 Uhr
#  96 (0x60) -> 24:00 Uhr
r,,HK1.ZP.Mo.1, ,,,,101A02,,,UIN,,,Zirkulationsprogramm Mo 1 Start/Ende (Anwender 161)


Außerdem hat der Heizkreisregler2 (Definitionen in 75.csv) eigentlich die selben Parameter wie der Heizkreisregler1 (35.csv).
Es würde Sinn machen, einen Symlink 75.csv -> 35.csv zu setzen, um die Definitionen nur einmalig machen zu müssen.
Allerdings müsste in den Definition für die Nachrichtentypen (*b, *w) abhängig vom Dateinamen die Zieladresse eingetragen werden und die Benamung der Nachrichten müsste auch dynamisch erfolgen.

Hast Du da einen Mechanismus vorgesehen?

35.csv

*r,HK1,,,,35,"0902",,,,,,,
*w,HK1,,,,35,"0903",,,,,,,

r,,HK1.T_Normal, ,,,,050002,,,temp10,,,Normaltemperatur Sollwert (Anwender 171)
w,,HK1.T_Normal, ,,,,0500,,,temp10,,,


75.csv

*r,HK2,,,,75,"0902",,,,,,,
*w,HK2,,,,75,"0903",,,,,,,

r,,HK2.T_Normal, ,,,,050002,,,temp10,,,Normaltemperatur Sollwert (Anwender 171)
w,,HK2.T_Normal, ,,,,0500,,,temp10,,,

john30

Zitat von: J0K3r am 10 Dezember 2016, 12:12:41
Wie soll ich denn eigenlich die Hex-Werte der Adressen schreiben, in Anführungszeichen oder nicht?  :-[
Die Anführungszeichen sind eher für Excel/Openoffice User, denn damit wird beim Import dann nicht versucht, den Wert als Zahl, Datum o.ä. zu interpretieren.

Zitat von: J0K3r am 10 Dezember 2016, 12:12:41
Hast Du einen Tipp für den Datentyp "Uhrzeit in Viertelstunden"?
Jeweils ein Byte für die Startzeit und die Endzeit. Lesen und schreiben kann man die beiden Werte nur zusammen (als Int16).
Hm, dafür braucht es einen neuen Datentyp. Da hast jetzt gerade das Release 2.4 verpasst, sonst hätt ichs Dir noch schnell einbauen können.
Im Prinzip brauchst Du nur folgende Zeile in lib/ebus/datatype.cpp nach Zeile 997 einfügen:
add(new DateTimeDataType("TTQ", 8, 0, 0, false, true, 15)); // truncated time (only multiple of 15 minutes), 00:00 - 24:00 (minutes div 15 + hour * 4 as integer)
Damit bekommst Du einen neuen Datentyp "TTQ" der genau das macht, was Du brauchst.

Zitat von: J0K3r am 10 Dezember 2016, 12:12:41
Außerdem hat der Heizkreisregler2 (Definitionen in 75.csv) eigentlich die selben Parameter wie der Heizkreisregler1 (35.csv).
Es würde Sinn machen, einen Symlink 75.csv -> 35.csv zu setzen, um die Definitionen nur einmalig machen zu müssen.
Allerdings müsste in den Definition für die Nachrichtentypen (*b, *w) abhängig vom Dateinamen die Zieladresse eingetragen werden und die Benamung der Nachrichten müsste auch dynamisch erfolgen.
Hast Du da einen Mechanismus vorgesehen?
Ja, da hätte sich mal wieder der Blick in wiki gelohnt ;)
Es genügt hier, in den Default Zeilen (die mit "*r/*w" am Zeilenanfang) die Adresse wegzulassen, dann wir die von ebusd aufgrund der Adresse im Dateinamen befüllt.

Alles klar? :)
VG John
author of ebusd

J0EK3R

#39
Hallo John!  ;D

Zitat von: john30 am 10 Dezember 2016, 14:34:37
Die Anführungszeichen sind eher für Excel/Openoffice User, denn damit wird beim Import dann nicht versucht, den Wert als Zahl, Datum o.ä. zu interpretieren.
OK, gutes Argument. Ich werde dann alle Hex-Werte umstellen...  ???

Zitat von: john30 am 10 Dezember 2016, 14:34:37
Hm, dafür braucht es einen neuen Datentyp. Da hast jetzt gerade das Release 2.4 verpasst, sonst hätt ichs Dir noch schnell einbauen können.
Damit bekommst Du einen neuen Datentyp "TTQ" der genau das macht, was Du brauchst.
Bei Gelegenheit werde ich das ausprobieren und den Quellcode lokal anpassen.
Wirst Du denn diesen neuen Datentyp "TTQ" auch ins Repository einpflegen?  ;D

Zitat von: john30 am 10 Dezember 2016, 14:34:37
Ja, da hätte sich mal wieder der Blick in wiki gelohnt ;)
Autsch! Getroffen! Das habe ich mir wohl verdient! ;)

Zitat von: john30 am 10 Dezember 2016, 14:34:37
Es genügt hier, in den Default Zeilen (die mit "*r/*w" am Zeilenanfang) die Adresse wegzulassen, dann wir die von ebusd aufgrund der Adresse im Dateinamen befüllt.
...ich (mein Bauchgefühl) wusste doch, dass da was war!  8)

Natürlich habe ich das gleich ausprobiert: die Zieladresse aus den Defaults entfernt und einen Symlink 75.csv -> 35.csv angelegt.
Dann die Konfigurationen neu eingelesen (ebusctl reload) und...  :'(

2016-12-11 11:32:11.031 [main error] error reading scan config file /etc/ebusd/kromschroeder/75.csv for ID "", SW2633, HW0000: ERR: duplicate name


Ich befürchte, dass diese Fehlermeldung von den dann doppelt vergebenen Namen der Nachrichten kommt (weil sie sich noch im selben Cycle befinden).

Ich müsste den Cycle-Namen der Defaults abhängig (vielleicht über eine Condition?) von der Adresse setzen können, dann würde alles funktionieren:


# Conditions - ???
*[Is35],scan,,,SW,35,
*[Is75],scan,,,SW,75,

# Default-Definitionen
# Zieladresse 35 -> cycle = HK1
[Is35]*r,HK1,,,,,"0902",,,,,,,

# Zieladresse 75 -> cycle = HK2
[Is75]*r,HK2,,,,,"0902",,,,,,,

# Parameterdefinitionen
r,,Außen, ,,,,"0c0002",,,temp10,,,Außentemperatur Ist
r,,Kessel, ,,,,"0d0002",,,temp10,,,Kessel Ist


Leider hat das so nicht funktioniert. Sind Conditions für Defaults denn überhaupt möglich?
Und wie sähe denn eine entsprechende Condition aus?
Oder bin ich auf dem Holzweg und es gibt eine einfache Lösung?

Viele Grüße
J0K3r

john30

Zitat von: J0K3r am 11 Dezember 2016, 12:33:42
Bei Gelegenheit werde ich das ausprobieren und den Quellcode lokal anpassen.
Wirst Du denn diesen neuen Datentyp "TTQ" auch ins Repository einpflegen?  ;D
ist schon drin.

Zitat von: J0K3r am 11 Dezember 2016, 12:33:42
Ich müsste den Cycle-Namen der Defaults abhängig (vielleicht über eine Condition?) von der Adresse setzen können, dann würde alles funktionieren:
ebusd holt sich aus dem Dateinamen auch noch einen optionalen Suffix, z.B. für die Nr. des Heizkreises. Z.B. macht der Symlink 7c.rcc.6.csv -> 75.rcc.csv aus der default circuit "rcc" der 75.rcc.csv dann "rcc.6" für die Adresse 7c.
Ob das auch ohne die ID (im Beispiel "RCC") im Dateinamen klappt, weiß ich grad nicht. Probiers mal.

Zitat von: J0K3r am 11 Dezember 2016, 12:33:42
Leider hat das so nicht funktioniert. Sind Conditions für Defaults denn überhaupt möglich?
Nein, für defaults gibts keine condition.
author of ebusd

J0EK3R

Hallo John,

ich habe den neuen Typ "TTQ" in die datatype.cpp hineingepatcht und mir einen neuen ebusd kompiliert.
Das hat soweit funktioniert, das Heizprogramm 1 in 35.csv ist bereits umgestellt und im Repository.

Auszug 35.csv - Start und End sind jeweils ein Byte vom Typ TTQ (Uhrzeit in Viertelstunden)

r,,HK1.HP1.Mo.1,Heizprogramm 1 Mo 1 Start/Ende (Anwender 121) ,,,,1014,Start,,TTQ,,,Start ,End,,TTQ,,,Ende
w,,HK1.HP1.Mo.1, ,,,,1014,Start,,TTQ,,,Start ,End,,TTQ,,,Ende
r,,HK1.HP1.Mo.2,Heizprogramm 1 Mo 2 Start/Ende (Anwender 121) ,,,,1114,Start,,TTQ,,,Start ,End,,TTQ,,,Ende
w,,HK1.HP1.Mo.2, ,,,,1114,Start,,TTQ,,,Start ,End,,TTQ,,,Ende
r,,HK1.HP1.Mo.3,Heizprogramm 1 Mo 3 Start/Ende (Anwender 121) ,,,,1214,Start,,TTQ,,,Start ,End,,TTQ,,,Ende
w,,HK1.HP1.Mo.3, ,,,,1214,Start,,TTQ,,,Start ,End,,TTQ,,,Ende


Das Auslesen funktioniert:

pi@raspberrypi:/etc/ebusd $ ebusctl r -f HK1.HP1.Mo.1
13:15;21:30

pi@raspberrypi:/etc/ebusd $ ebusctl r -f -v HK1.HP1.Mo.1
HK1 HK1.HP1.Mo.1 Start=13:15;End=21:30


Das Setzen der Werte bekomme ich allerdings nicht hin:

pi@raspberrypi:/etc/ebusd $ ebusctl w -c HK1 HK1.HP1.Mo.1 13:15;21:30
ERR: end of input reached

-bash: 21:30: Kommando nicht gefunden.


...bestimmt mach ich wieder etwas falsch...  :-X

Zitat von: john30 am 11 Dezember 2016, 13:10:48
ebusd holt sich aus dem Dateinamen auch noch einen optionalen Suffix, z.B. für die Nr. des Heizkreises. Z.B. macht der Symlink 7c.rcc.6.csv -> 75.rcc.csv aus der default circuit "rcc" der 75.rcc.csv dann "rcc.6" für die Adresse 7c.
Ob das auch ohne die ID (im Beispiel "RCC") im Dateinamen klappt, weiß ich grad nicht. Probiers mal.
Nein, für defaults gibts keine condition.
Das Ändern des Circuits anhängig vom Dateinamen/Symlink bzw. das Anhängen eines Suffix an den Heizkreis hat so leider nicht funktioniert. Meine Heizkreisregler melden sich ja leider nicht mit einer ID, somit musste ich den ID-Teil im Dateinamen weglassen.
Da kommt dann so etwas heraus: 35..csv :-\
Das Anhängen eines Suffix hat dann auch nicht funktioniert. Meine Idee war 35..HK1.csv und 75..HK2.csv zu verwenden, der jeweilige Suffix würde den leeren Id-String dann entsprechend nach HK1 und HK2 erweitern.


pi@raspberrypi:/etc/ebusd $ ebusctl info
version: ebusd 2.3.24d8e75
... schnipp ...
address 35: slave #3, scanned "MF=Kromschroeder;ID=;SW=2633;HW=0000", loaded "kromschroeder/35.csv"
address 75: slave #4, scanned "MF=Kromschroeder;ID=;SW=2633;HW=0000", loaded "kromschroeder/75.csv"


Naja...  :'(

john30

Zitat von: J0K3r am 11 Dezember 2016, 18:54:55
ich habe den neuen Typ "TTQ" in die datatype.cpp hineingepatcht und mir einen neuen ebusd kompiliert.
das hättest Du gar nicht müssen, ein einfaches git pull hätte genügt.

Zitat von: J0K3r am 11 Dezember 2016, 18:54:55
Das Setzen der Werte bekomme ich allerdings nicht hin:

pi@raspberrypi:/etc/ebusd $ ebusctl w -c HK1 HK1.HP1.Mo.1 13:15;21:30
ERR: end of input reached
-bash: 21:30: Kommando nicht gefunden.

Da Du in der Kommandozeile bist, musst Du wegen des Strichpunkts den Werte-Teil in Anführungszeichen setzen.

Zitat von: J0K3r am 11 Dezember 2016, 18:54:55
Das Ändern des Circuits anhängig vom Dateinamen/Symlink bzw. das Anhängen eines Suffix an den Heizkreis hat so leider nicht funktioniert. Meine Heizkreisregler melden sich ja leider nicht mit einer ID, somit musste ich den ID-Teil im Dateinamen weglassen.
Da kommt dann so etwas heraus: 35..csv :-\
Das Anhängen eines Suffix hat dann auch nicht funktioniert. Meine Idee war 35..HK1.csv und 75..HK2.csv zu verwenden, der jeweilige Suffix würde den leeren Id-String dann entsprechend nach HK1 und HK2 erweitern.
Der Suffix ist maximal eine Zahl, also mit ".HK" geht es sicher nicht.
author of ebusd

J0EK3R

Zitat von: john30 am 11 Dezember 2016, 20:31:12
das hättest Du gar nicht müssen, ein einfaches git pull hätte genügt.
Sicher?  :-X

...bin zwar nicht der git-Experte, aber in datatype.cpp finde ich auch nach dem git pull besagten Typ "TTQ" nicht...  :o

J0EK3R

Zitat von: john30 am 11 Dezember 2016, 20:31:12
Da Du in der Kommandozeile bist, musst Du wegen des Strichpunkts den Werte-Teil in Anführungszeichen setzen.

OK - wieder was gelernt!  ;D

So geht's:

pi@raspberrypi:/etc/ebusd $ ebusctl w -c HK1 HK1.HP1.Mo.1 "13:15;21:30"
done

pi@raspberrypi:/etc/ebusd $ ebusctl r -f HK1.HP1.Mo.1
13:15;21:30


Ich war fleisig und habe alle Programme in der 35.csv auf den Datentyp "TTQ" umgestellt und ins Repository gepusht. Puh!  ::)