eBus Schaltung Rpi in Betrieb nehmen!

[JimKnopf]

Ich habe in meiner Konfiguration bei MQTT2 folgenden Timer im Einsatz (alle 5 Minuten folgende Messwerte):

Code Auswählen Erweitern

+*00:05:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/Status02/get;
set ebusMQTT publish ebusd/bai/HcHours/get;
set ebusMQTT publish ebusd/bai/HwcStarts/get

Hallo Reinhard!
Vielen Dank für das Beispiel. "ebusd/bai/HwcStarts" z.B. soll wohl identisch mit den Eintragungen unter attr ebusMQTT readingList sein oder?
In meiner CVS steht z.B.:

Code Auswählen Erweitern

r,solar,ertraege,,07,76,5022,02f902,betriebsstunden,,UIN,,Betriebsstunden
In der readingList demnach:

Code Auswählen Erweitern

ebusd/solar/ertraege:.* { json2nameValue($EVENT, 'betriebsstunden', $JSONMAP) }

dann müsste ich im Timer:

Code Auswählen Erweitern

set ebusMQTT publish ebusd/solar/ertraege/get
setzen. Wäre das so richtig? Scheint zumindest funktioniert zu haben.
Gruß,
Burhard

[TomLee]

Mal zum "Timer" noch eine Alternative die man direkt im MQTT2_DEVICE umsetzen kann:

periodicCmd i.V.m dem entsprechenden get-Kommando.

Sollte dann an Hand dem Readinglisteintrag oben so klappen:

Code Auswählen Erweitern

attr <MQTT2_DEVICENAME> getList <irgendeinnamefürdengetter>:noArg betriebsstunden ebusd/solar/ertraege/get

Code Auswählen Erweitern

attr <MQTT2_DEVICENAME> periodicCmd betriebsstunden:10

Hole die betriebsstunden alle 10 Minuten oder manuell über den getList-Eintrag.

Gruß

Thomas

[Eraser]

So, habe nun ebusd komplett deinstalliert und bin dann für die Installation den Weg mit dem gpgkey gegangen:

https://github.com/john30/ebusd-debian/blob/master/README.md

Hat einwandfrei geklappt und nun funktioniert alles wieder.
Danke für eure Hilfe!

Jetzt muss ich mich erstmal in das Thema MQTT bei ebusd genauer einlesen.

Anhand der letzten Beiträge und meinem begrenzten Grundwissen derweil von MQTT ist folgendes meiner Meinung nach nicht möglich:

-) Ein periodisches Auslesen von Werten aus dem Pi von einem externen Gerät aus
   => es muss direkt am Pi das Intervall eingegeben werden

Dies funktioniert so nicht, da MQTT ja darauf aufbaut, dass jemand eine Nachricht nur zum Server sendet und dieser dann je nach Abonnement zu anderen Geräten weiterleitet.
Dadurch gibt es bei MQTT im Endeffekt kein direktes Auslesen oder?

Wie funktioniert dann das Werte schreiben bei MQTT?
Angenommen ich will von einem externen Gerät, dass auch mit dem gleichen MQTT-Broker verbunden ist, einen Wert in die Steuerung schreiben (z.B. Temperatur ändern).
Muss dann im Endeffekt der Pi mit ebusd genauso ein Abonnement von den gleichen Werten haben, die er auch sendet?

mfg
Wolfgang

[Damian]

Man kann sehr wohl periodisch Daten per MQTT abfragen sowie setzen.

Bei mir läuft ebus von john30 auf einem separten Pi, an dem die Therme (Vaillant) über ebus angebunden ist. Von dort findet die Kommunikation zum FHEM-Server auf einem anderen Pi per MQTT statt.

So sieht bei mir das MQTT-Device auf dem FHEM-Server aus:

Code Auswählen Erweitern

defmod vaillant MQTT2_DEVICE ebusd_bai
attr vaillant IODev MQTT2_FHEM_Server
attr vaillant devStateStyle style="text-align:left"
attr vaillant event-on-change-reading .*
attr vaillant group Ebus
attr vaillant icon sani_boiler_temp
attr vaillant jsonMap Status01_0_value:Vorlauf Status01_0_name:0\
Status01_1_value:Ruecklauf Status01_1_name:0\
Status01_2_value:Aussentemp Status01_2_name:0\
Status01_3_value:Warmwasser Status01_3_name:0\
Status01_4_value:WWSpeicher Status01_4_name:0\
Status01_5_value:Pumpenstatus Status01_5_name:0\
Flame_0_value:Flame Flame_0_name:0\
Storageloadpump_percent0_value:Storageloadpump\
FlowTempDesired_temp_value:VorlaufSoll\
Hc1HeatCurve_0_value:HeizKennlinie Hc1HeatCurve_0_name:0\
HolidayEndPeriod_hto_value:FerienEnde\
HolidayStartPeriod_hfrom_value:FerienBeginn\
PumpPower_0_value:PumpenLeistung PumpPower_0_name:0\
PrimaryCircuitFlowrate_uin100_value:Umlaufmenge\
z1DayTemp_tempv_value:TagSolltemp\
z1NightTemp_tempv_value:NachtSolltemp\
FanSpeed_0_value:LuefterDrehzahl FanSpeed_0_name:0\
WaterPressure_pressv_value:Wasserdruck\
z1OpMode_opmode_value:Heizmodus
attr vaillant model eBus_bai_jsonmap
attr vaillant readingList ebusd/bai/PumpHours:.* { json2nameValue($EVENT, 'PumpHours_', $JSONMAP) }\
ebusd/bai/WPPostrunTime:.* { json2nameValue($EVENT, 'WPPostrunTime_', $JSONMAP) }\
ebusd/bai/PowerValue:.* { json2nameValue($EVENT, 'PowerValue_', $JSONMAP) }\
ebusd/bai/StorageExitTemp:.* { json2nameValue($EVENT, 'StorageExitTemp_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/scan\x5c\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }\
ebusd/scan\x5c\x2e08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/global/uptime:.* uptime\
ebusd/global/signal:.* signal\
ebusd/scan\x5c\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\x5c\x2e15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }\
ebusd/bai/PumpPower:.* { json2nameValue($EVENT, 'PumpPower_', $JSONMAP) }\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }\
ebusd/global/updatecheck:.* updatecheck\
ebusd/bai/DCFTimeDate:.* { json2nameValue($EVENT, 'DCFTimeDate_', $JSONMAP) }\
ebusd/bai/PumpPowerDesired:.* { json2nameValue($EVENT, 'PumpPowerDesired_', $JSONMAP) }\
ebusd/bai/HwcImpellorSwitch:.* { json2nameValue($EVENT, 'HwcImpellorSwitch_', $JSONMAP) }\
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }\
ebusd/700/HwcStorageTempBottom:.* { json2nameValue($EVENT, 'HwcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/bai/FanPWMSum:.* { json2nameValue($EVENT, 'FanPWMSum_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HoursTillService:.* { json2nameValue($EVENT, 'HoursTillService_', $JSONMAP) }\
ebusd/bai/PumpHwcFlowNumber:.* { json2nameValue($EVENT, 'PumpHwcFlowNumber_', $JSONMAP) }\
ebusd/bai/WP:.* { json2nameValue($EVENT, 'WP_', $JSONMAP) }\
ebusd/700/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/PrimaryCircuitFlowrate:.* { json2nameValue($EVENT, 'PrimaryCircuitFlowrate_', $JSONMAP) }\
ebusd/bai/Flame:.* { json2nameValue($EVENT, 'Flame_', $JSONMAP) }\
ebusd/bai/Storageloadpump:.* { json2nameValue($EVENT, 'Storageloadpump_', $JSONMAP) }\
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT, 'FlowTempDesired_', $JSONMAP) }\
ebusd/700/FrostOverRideTime:.* { json2nameValue($EVENT, 'FrostOverRideTime_', $JSONMAP) }\
ebusd/700/Hc1ActualFlowTempDesired:.* { json2nameValue($EVENT, 'Hc1ActualFlowTempDesired_', $JSONMAP) }\
ebusd/700/Hc1AutoOffMode:.* { json2nameValue($EVENT, 'Hc1AutoOffMode_', $JSONMAP) }\
ebusd/700/Hc1CircuitType:.* { json2nameValue($EVENT, 'Hc1CircuitType_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/HcStorageTempBottom:.* { json2nameValue($EVENT, 'HcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HcStorageTempTop:.* { json2nameValue($EVENT, 'HcStorageTempTop_', $JSONMAP) }\
ebusd/700/HolidayTemp:.* { json2nameValue($EVENT, 'HolidayTemp_', $JSONMAP) }\
ebusd/700/OpMode:.* { json2nameValue($EVENT, 'OpMode_', $JSONMAP) }\
ebusd/700/z1RoomTemp:.* { json2nameValue($EVENT, 'z1RoomTemp_', $JSONMAP) }\
ebusd/700/z1SFMode:.* { json2nameValue($EVENT, 'z1SFMode_', $JSONMAP) }\
ebusd/700/z1OpMode:.* { json2nameValue($EVENT, 'z1OpMode_', $JSONMAP) }\
ebusd/700/Time:.* { json2nameValue($EVENT, 'Time_', $JSONMAP) }\
ebusd/bai/EbusVoltage:.* { json2nameValue($EVENT, 'EbusVoltage_', $JSONMAP) }\
ebusd/bai/extWP:.* { json2nameValue($EVENT, 'extWP_', $JSONMAP) }\
ebusd/bai/FanStarts:.* { json2nameValue($EVENT, 'FanStarts_', $JSONMAP) }\
ebusd/700/z1NightTemp:.* { json2nameValue($EVENT, 'z1NightTemp_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/700/HolidayStartPeriod:.* { json2nameValue($EVENT, 'HolidayStartPeriod_', $JSONMAP) }\
ebusd/700/HolidayEndPeriod:.* { json2nameValue($EVENT, 'HolidayEndPeriod_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHc1:.* { json2nameValue($EVENT, 'PrEnergyCountHc1_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHwc1:.* { json2nameValue($EVENT, 'PrEnergyCountHwc1_', $JSONMAP) }\
ebusd/bai/PrEnergySumHc1:.* { json2nameValue($EVENT, 'PrEnergySumHc1_', $JSONMAP) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }
attr vaillant room Ebus,MQTT2_DEVICE
attr vaillant setList HeizKennlinie:selectnumbers,0,.1,2,1,lin ebusd/700/Hc1HeatCurve/set $EVTPART1\
TagSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1DayTemp/set $EVTPART1\
NachtSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1NightTemp/set $EVTPART1


Und so wurde das periodische Auslesen (MQTT2_FHEM_Server publish ebusd/bai/.../get) und Visualisieren realisiert (Ergebnis siehe Anhang):

Code Auswählen Erweitern

defmod di_vaillant DOIF ##{[+00:01];;foreach (qw(FanSpeed Flame PumpPower Storageloadpump PrimaryCircuitFlowrate FlowTempDesired PumpHours HcHours HcPumpStarts)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
{[+00:00:30];;foreach (qw(Flame PrimaryCircuitFlowrate)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
{[00:01];;foreach (qw(PrEnergyCountHc1 PrEnergyCountHwc1 PrEnergySumHc1 PrEnergySumHwc1 FanHours HcHours HwcHours HcStarts HwcStarts)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
{[+01:00];;foreach (qw(z1OpMode WaterPressure z1NightTemp z1DayTemp Hc1HeatCurve HwcLockTime HolidayStartPeriod HolidayEndPeriod)) {fhem_set("MQTT2_FHEM_Server publish ebusd/700/$_/get")}}\
{if ([00:05|WE] or [FS20_fa4b02]) {fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayStartPeriod/set $mday.$month.$year");;fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayEndPeriod/set $mday.$month.$year")}}
attr di_vaillant event-on-change-reading .*
attr di_vaillant room Ebus
attr di_vaillant uiTable {\
  package ui_Table;;\
  $TC{0..8}="align='center'";;\
  $TD{3}{0..1}="colspan=3";;\
  $TD{4}{0..1}="colspan=3";;\
  $TD{5}{0..2}="colspan=2";;\
  $TD{7}{0..1}="colspan=3";;\
  $TD{8}{0}="colspan=6";;\
}\
\
style("Außen","Darkorange")|style("Therme","Darkorange")|style("WW-Sp.","Darkorange")|style("Zirk.","Darkorange")|style("Vorlauf","Darkorange")|style("Rücklauf","Darkorange")\
ICON("temp_outside")|\
icon([vaillant:Flame],"sani_boiler_temp","sani_boiler_temp\@Darkorange")|\
ICON([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down")|\
icon([Zirk],"sani_pump")|\
ICON([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating_neutral\@Darkorange" : "sani_floor_heating_neutral")|\
ICON("sani_floor_heating_neutral")\
temp_bar([vaillant:Aussentemp],-15,40)|\
temp_bar([vaillant:Vorlauf],15,70)|\
temp_bar([vaillant:WWSpeicher],15,70)|\
temp_bar([ESPEasy_ESP_Temp_Zirkulation:Temperature],15,45)|\
temp_bar([ESPEasy_ESP_Temp_Vorlauf:Temperature],15,45)|\
temp_bar([ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature],15,45)\
##"&nbsp"\
style("Umlaufmenge","Darkorange")|style("Wasserdruck","Darkorange")\
ring([vaillant:Umlaufmenge],0,20,120,0,"l/min",120)|ring([vaillant:Wasserdruck],0,3,0,180,"bar",120)\
##"&nbsp"\
style("Heizkennlinie","Darkorange")|style("Tagtemperatur","Darkorange")|style("Nachttemperatur","Darkorange")\
ICON("time_graph")|WID([vaillant:HeizKennlinie],"selectnumbers,0.4,.1,1,1,lin","set")|\
ICON("scene_day\@yellow")|temp_knob([vaillant:TagSolltemp],"yellow")|\
ICON("scene_night\@#3464eb")|temp_knob([vaillant:NachtSolltemp],"#3464eb")\
[vaillant:HcHours_hoursum2_value]. " Std."|[vaillant:HwcHours_hoursum2_value]." Std."\
##"Ferien"|ICON(::IsWe()?"fa_check\@Darkorange":"fa_check_empty")\
##WID([$SELF:Timer_1],"time")|WID([$SELF:Timer_2],"time")|WID([$SELF:Timer_3],"time")|WID([$SELF:Timer_4],"time")\
::SVG_FwFn("WEBHOME","P01","",{})\
\


[Eraser]

Hallo Damian,

super danke, schaut sehr gut aus deine Umsetzung!

Da du ja auch eine Vaillant damit ausliest, bekommst du bei dir auch diese nicht erkennbaren Telegramme?

Code Auswählen Erweitern


localhost: grab result all
3105070400 / 0ab5565239323020075703 = 1: scan.05
3105b5090127 / 094e3500000000000000 = 3: scan.05 id
3108070400 / 0ab5484d55303003070403 = 1: scan.08
3108b5090127 / 094e383c3c3c3c3c3c3c = 3: scan.08 id
3115070400 / 0ab5373030303005106403 = 1: scan.15
3115b5090127 / 094e3800000000000000 = 3: scan.15 id
3138070400 / 0ab5563332000001179802 = 1: scan.38
3176070400 / 0ab556575a303003070403 = 1: scan.76
3176b5090127 / 00 = 3907: scan.76 id
03e0070400 / 0ab54f4d55303001315202 = 25: scan.e0
31e0b5090127 / 094e303c3c3c3c3c3c3c = 3: scan.e0 id
1008b51009000000ffffff070000 / 0101 = 922: hmu SetMode
10feb516080016581430080720 = 154: broadcast vdatetime
10feb51603013017 = 153: broadcast outsidetemp
1008b5040100 / 0a0327221230080720a013 = 1: hmu DateTime
1008b507010a / 03828207 = 3
1008b5110100 / 09900114000000000100 = 155
1008b5110101 / 093232a013ff590000ff = 2: hmu Status01
1076b5110101 / 09ff313017ff520000ff = 924
10feb505025c00 = 156
10feb508020900 = 16
10feb510020601 = 31
10feb516080024221230080720 = 1: broadcast vdatetime
3105b5090124 / 09003231313835303030 = 1: scan.05 id
3108b5090124 / 09003231313735303030 = 1: scan.08 id
3115b5090124 / 09003231313830363030 = 1: scan.15 id
3176b5090124 / 00 = 1: scan.76 id
31e0b5090124 / 09003231313830373030 = 1: scan.e0 id
1008b5040100 / 0a03195814300807203017 = 154: hmu DateTime
1008b5110101 / 0932313017ff520000ff = 899: hmu Status01
0008b503020002 / 0affffffffffffffffffff = 9
0008b503020004 / 0affffffffffffffffffff = 10
0015b503020002 / 0affffffffffffffffffff = 10
1008b507020900 / 02a402 = 156
1008b512020064 / 00 = 31
1008b5120204ff / 0101 = 31
1008b513020528 / 0101 = 31
0008b503020001 / 0affffffffffffffffffff = 9: hmu currenterror
0015b503020001 / 0affffffffffffffffffff = 10: 700 currenterror
1076b512030f0201 / 0790020000801405 = 924
1076b51303040d00 / 02ffff = 154
0008b51608100000ff83050000 / 0b00000483051e2900e88049 = 12
0015b51608100000ff41030000 / 0b00000241031e2900000000 = 2
0033b5170608b503020004 = 42
1008b51009000000ffffff070000 / 0101 = 2: hmu SetMode
1076b51009000000ffffff050000 / 0101 = 924
03e0b5210900002214e4ffff4600 / 0b000040013a010700000600 = 280
3300b5180affffffffffffffffffff = 39
3310b5180affffffffffffffffffff = 1


Weißt du etwas genaueres darüber, was diese sind? Alive-Nachrichten? Abragen auf vorhandenen Busteilnehmer?


@Reinhart:

Deine zeitliche Abfrage aus Post#374 wäre eine sehr einfache und leicht handzuhabende Möglichkeit.

Kannst du mir bitte erklären, wo du den geposteten Code hinterlegt hast?
Als Befehle direkt eingegeben oder in einer config-Datei hinterlegt?

Vielen Dank

mfg
Wolfgang

[Eraser]

Hallo Reinhart,

hab durch Nachlesen im FHEM-Forum rausgefunden, dass deine Befehle usw. in FHEM eingegeben werden.
Darum kam es mir spanisch vor, weil ich kein FHEM einsetze.

Muss ich wohl eine andere Lösung suchen, aber danke.

[thomas.z]

Moin,
ich bin gerade dabei, den RPI-Adapter in Betrieb zu nehmen. Folgende Schritte habe ich ausgeführt:
- Spannungen gemessen mit Versorgung am ebus-Eingang und den 5V anstelle des RPI, ok.
- RPI mit tyyebus Treiber versehen und Adapter aufgesteckt.
- Test mit schreiben auf /dev/ttyebus gemacht.
  Mit  echo "Hello World" > /dev/ttyebus und
  while [ 1 ]; do  cat /var/log/daemon.log > /dev/ttyebus ; done
- Mit Scope das Signal kontorlliert.

Das sah erstmal gut aus. Jedoch bekomme ich Meldungen , die mich irritiren:

Bei 3X"Hello World" bekomme ich folgende Einträge in den logs:
dmesg:
[   46.945338] ttyebus: Close at at major 10  minor 61
[   46.945344] ttyebus: Close exit
[   55.144820] ttyebus: Close at at major 10  minor 61
[   55.144830] ttyebus: Close exit
[   62.680863] ttyebus: Close at at major 10  minor 61

/var/log/messages
Sep 12 12:29:53 rpiebusd kernel: [   46.945338] ttyebus: Close at at major 10  minor 61
Sep 12 12:30:01 rpiebusd kernel: [   46.945344] ttyebus: Close exit
Sep 12 12:30:01 rpiebusd kernel: [   55.144820] ttyebus: Close at at major 10  minor 61
Sep 12 12:30:09 rpiebusd kernel: [   55.144830] ttyebus: Close exit
Sep 12 12:30:09 rpiebusd kernel: [   62.680863] ttyebus: Close at at major 10  minor 61

Außerdem hat mich irritiert, dass beim Senden auch imm die Empfangs-LED leuchtet. Ich habe mir die Schaltung  daraufhin genauer angeschaut und wenn ich nicht völlig daneben liege, muss dass auch so sein, da die Eingangsstufe des OP-Amps nicht unterscheiden kann, ob der RPI ein Signal auf den Bus gelegt hat, oder eine Therme.

Die Meldungen bedeuten (gemäß anderer Einträge im Thread), dass der Eingangspuffer des UART überläuft. Da holt ja auch kein Prozess etwas ab.

Bevor ich den RPI nun an die Heizung hänge, möchte ich gerne wissen, ob das Verhalten so korrekt ist, weil der ebusd sein eigenes Signal gleich wieder mit ausliest?

Ansonsten bleibt noch ein herzliches Dankeschön an die Macher der Soft- und Hardware!

Viele Grüße
Thomas

Edit: Ich habe doch noch ein wenig weiter nachgedacht (hilft manchmal). Der ebusd muss ja zeitgleich das Busssignal mitlesen, um sein byte mit dem Gelesenen zu vergleichen, damit die Arbitrierung funktioniert ...
Sorry wg. der überflüssigen Frage.

[JimKnopf]

Hi!
Ich würde davon ausgehen, dass das normal ist.
Du brauchst wohl auch keine Angst zu haben, dass etwas passiert, wenn Du die Schaltung mit dem Ebus verbindest. Du wirst dann eine Menge echter Daten empfangen und Deine Anlage nicht iriitieren, solange Du noch nichts selbst sendest.
Aber auch wenn Du sendest dürfte nicht viel passieren. Im schlimmsten Fall würdest Du den Bus blockieren, was Du daran erkennst, dass auf den Anzeigen sich die Werte nicht mehr ändern.

Gruß,
Burkhard

[john30]

Edit: Ich habe doch noch ein wenig weiter nachgedacht (hilft manchmal). Der ebusd muss ja zeitgleich das Busssignal mitlesen, um sein byte mit dem Gelesenen zu vergleichen, damit die Arbitrierung funktioniert ...

genau

[Eraser]

Hallo,

Ich kann nun erfolgreich verschiedene Werte mittels

Code Auswählen Erweitern

--pollinterval 10 in der config-Datei und danach mittels z.B.

Code Auswählen Erweitern

r -p 1 HwcStorageTemp in ebusctl den Wert zyklisch auslesen.
Das dies erfolgreich ist, sehe ich aber nur in der ebusd.log, nicht aber mittels dem Befehl

Code Auswählen Erweitern

listen in ebusctl.
Was ist der Grund hierfür? Kann mir das jemand erklären?

Wie wäre die Vorgehensweise, wenn man mehrere Werte pollen will und dies automatisch auch nach einem Neustart passieren soll?
Nach einem Neustart muss dies das zyklische Auslesen der gewünschten Werte explizit in ebusctl per z.B.

Code Auswählen Erweitern

r -p 1 HwcStorageTemp wieder gestartet werden.
Ein Skript dafür schreiben?

Danke

mfg Wolfgang

[john30]

Das dies erfolgreich ist, sehe ich aber nur in der ebusd.log, nicht aber mittels dem Befehl

Code Auswählen Erweitern

listen in ebusctl.
Was ist der Grund hierfür? Kann mir das jemand erklären?

listen führt nur wirklich geänderte Messages auf.

Wie wäre die Vorgehensweise, wenn man mehrere Werte pollen will und dies automatisch auch nach einem Neustart passieren soll?
Nach einem Neustart muss dies das zyklische Auslesen der gewünschten Werte explizit in ebusctl per z.B.

Code Auswählen Erweitern

r -p 1 HwcStorageTemp wieder gestartet werden.
Ein Skript dafür schreiben?

z.B.
alternativ die config files lokal clonen und z.B. r1 fix bei den eintragen, die gepollt werden sollen

[Eraser]

Danke für deine Erklärung John,

hab da noch eine andere Frage bzgl. Poll-Intervall auf der github-Seite erstellt:
https://github.com/john30/ebusd/issues/360

Die Frage dabei ist, warum bei r -p 6 <Variable> kein Unterschied zu r -p 1 <Variable> besteht.
Es wird immer im hinterlegten --pollinterval=10 abgefragt und nich bei z.B. 10s*6=60s.

Kannst du dazu noch was sagen?
Danke für deine Hilfe und natürlich für ebusd!

mfg
Wolfgang

[JimKnopf]

Hi John!

Komschröder/Wolf ist ja sehr speziell vorgegangen wenn es um das setzen von Werten per eBus geht.
Um z.B. die Betriebsart der Anlage zu setzen muss ich folgendes senden:
ff3050230984120101005d010000.
ff305023 09 ist ja soweit standard und klar
84 = Prüfziffer, der Wert ist aber letztendlich egal, da die Anlage jeden Wert akzeptiert
1201 = id des Parameters
0100 = eigentlich zu übertragender Wert
5d010000= suffix

Meine Vorstellung wie ein csv Eintrag dafür aussehen könnte:
w,ISM7,Mode,,ff,30,5023,?1201,,mode,,UIN,0x0001=Standby;0x0002=Automatik;0x0003=Heizbetrieb;0x0004=Absenkbetrieb;0x0005=Sommer,mode,suffix,5d010000 #(das Fragezeichen als Platzhalter. Wird dieses Telegram mitgeschnüffelt wird jede Zahl akzeptiert. Soll gesendet werden wird eine zufällige oder feste Zahl gewählt)

damit in ebusctl "write -c ISM7 mode 01" den obigen Hexcode ergibt. Bei diesem write gibt es übrigens keine Antwort von der Anlage.
Wichtig!:
w,ISM7,Standby,,ff,30,5023,84120101005d010000
ebusctl: write -c ISM7 Standby
funktioniert nicht,
r,ISM7,Standby,,ff,30,5023,84120101005d010000
ebusctl: read -c ISM7 Standby
dagegen schon.

Wäre es möglich sowas in ebusd einzubauen?
Gruß,
Burkhard

[JimKnopf]

So, ich unterhalte mich mal wieder weiter mit mir selbst  .

Wie bereits erwähnt ist die Prüfsumme egal, sie wird nicht gegengeprüft. Jetzt habe ich festgestellt, dass der Anhang "5d010000" auch einfach weggelassen werden kann.
Somit sieht die Zeile in der CSV wie folgt aus:
w,ISM7,Mode,,ff,30,5023,021201,mode,,UIN,0x0001=Standby;0x0002=Automatik;0x0003=Heizbetrieb;0x0004=Absenkbetrieb;0x0005=Sommer,Mode

In ebusctl kann jetzt mit :
write -c ISM7 Mode Automatik
direkt umgestellt werden.

Das mitschnüffeln funktioniert natürlich so nicht, da wir die Prüfziffer nicht vorhersagen können und somit die ID nicht stimmt. Das halte ich aber für verschmerzbar, denn in den regelmäßigen broadcasts werden die neu gesetzten Werte ja regelmäßig bestätigt.
Gruß,
Burkhard

[JimKnopf]

Hi!

Die Heizung sedet einen Wert, der Bitweise kodiert ist. Als Beispiel: bit 0 = 3-Wegeventil, bit1 = Flamme, bit 4 = Kesselkreispumpe.

Ich vermute mal das die datatypes BI0  bis BI7 dafür gedacht sind, aber leider gibt es kein Beispiel für diesen Einsatz.
Kann mich jemand da aufklären?

Hat sich erledigt, mit viel experimentieren hab ich es selbst rausgefunden. Danke.

Gruß,
Burkhard