ebusd.mqtt2.template: Fragen, Anregungen

[Beta-User]

Hatte jetzt AttrTemplate.pm aus dem svn (19002) gezogen, sonst scheint ja kein Modul betroffen gewesen zu sein.

Das klappte auf meinen Testsystem so aber leider nicht, der room wurde nicht zutreffend bestimmt (doppeltes MQTT2_), und das farewell wurde auch nicht wie erwartet angezeigt.
Letzteres könnte daran liegen, dass beide templates (ich hatte das noch in den tasmota-shutter eingebaut) "deletereading"-Anweisungen enthalten, also schon ein asynchoner output da ist.
Beim GeneralBridge-Template kommt dazu, dass durch den Raumwechsel auch sofort der Hinweis auf die gelöschten Readings verschwindet wegen des Wechsels der angezeigten Seite (da ist es aber nicht tragisch, war eh' eher ein Test).

Ich habe jetzt die "should-work"-Version des template-files ins svn geschoben, geht ja nichts wirklich kaputt und du kannst ggf. leichter testen.

[rudolfkoenig]

Die erste Ursache war deletereading: sie meldet, was sie entfernt hat.
Wenn ein attrTemplate Befehl etwas zurueckliefert, dann wird das als Fehler eingestuft und per dialog gemeldet, und farewell nicht angezeigt.
=> ich habe fhem.pl erweitert, dass man deletereading mit -q (for quiet) aufrufen kann, das wuerde ich fuer attrTemplate generell empfehlen.
Apropos: setreading gefolgt von deletereading ist optimierungsbeduerftig.

Das zweite Problem ist, dass je nach set/reload Kombination fw_id verloren geht, und damit funktioniert asyncOutput nicht: FHEMWEB weisst nicht mehr, wem es senden soll.
=> ich habe fhemweb.js angepasst, damit beim set und attr fw_id weitergegeben wird.

[Beta-User]

Puh, da hast du ganz schön viel Arbeit mit gehabt, dafür, dass du eigentlich Arbeit delegieren wolltest...

Danke für den Hinweis mit der Reihenfolge set+delete , hoffe, alle fraglichen Stellen erwischt zu haben.
Ansonsten hab ich's nur kurz getestet und bin mal gespannt, ob ich noch irgendwas relevantes übersehen habe...

Btw: Bei den Usern scheint das mit den attrTemplate's sehr gut anzukommen; man hört kaum was negatives, die Statistik spricht Bände und das handling aus Usersicht könnte m.E. jetzt kaum noch einfacher sein...
War also eine echt klasse Idee von Dir mit diesem feature und den ganzen "Arbeiten drumrum"!   

(Auch wenn ich selbst auch einiges an Arbeit damit hatte , aber es wird weniger, wir scheinen für die "typsichen" Fälle einen einigermaßen konsolidierten Stand zu haben, und ich selbst habe auch einiges dabei gelernt).

[Reinhart]

wollte euch kurz Rückmeldung geben, die letzte Änderung von Rudolf funktioniert nun perfekt. Habe das SVN 19002 von 12:37 genommen.

Code Auswählen Erweitern

name:E_06a_eBus_bai_devStateIcon_Waterpressure
filter:TYPE=MQTT2_DEVICE
desc:Pressure of Watersystem
par:DEV_ID;name of the device ebus;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
defmod MQTT2_ebusd_pressure MQTT2_\DEVICE ebusd_pressure
attr MQTT2_ebusd_pressure IODev ebusMQTT
attr MQTT2_ebusd_pressure devStateIcon {my $vD = ReadingsVal("MQTT2_ebusd_bai", "WaterPressure_press_value", "1"); my $colDruck = substr(Color::pahColor(0,1,2,$vD,0),0,6); my $iconDruck = 'weather_barometric_pressure@'.$colDruck; ; "<div style=\"text-align:right\" > Wasserdruck: " . FW_makeImage("$iconDruck",'file_unknown@grey') . int($vD*100)/100 . " Bar</div>"}
attr MQTT2_ebusd_pressure icon vacuum_bold
attr MQTT2_ebusd_pressure room MQTT2_\DEVICE
attr MQTT2_ebusd_pressure model E_06a_eBus_bai_Pressure
Auch beim Anlegen des Device ist der Backslash \ sehr nützlich.

Meine Vorstellung ist ja so, der von autocreate angelegte Device ist zu 80% ist eine "bai" und die kann ja ein paar 100 Readings enthalten, da ist man mit devStateIcon schnell am Ende weil man einfach die Übersicht verliert. Durch die Trennung in eigenen Rooms geht das perfekt und die Quelldevices bleiben für den Anwender frei zur Verfügung wenn er was dazu basteln will. Die meisten Anwender wollen sich ja die Messdaten logisch unterteilen (Heizkessel, Wärmepumpen etc.) damit das eine schöne Übersicht ergibt, da steht nun nichts mehr im Wege.

Ich habe hier zusätzlich noch die "group" definiert und kann somit indirekt die Anordnung/Reihenfolge beeinflussen.

Danke für eure Geduld!

@Beta-User
wo brauch ich denn die DEVCID zwingend?

LG
Reinhart

[Beta-User]

 

Reinhart, das sieht ja schon mal cool aus!
(Du kannst übrigens gerne auch readingGroups bauen oder ableiten, das wäre für mich auch ok).

Das mit der DEVCID brauchte ich nur für das GeneralBridge-template, das geht bei deinem Beispiel und vermutlich den anderen, die du da im Auge hast auch so. Würde nur anregen, den Filter noch etwas einzuengen - müßte über

Code Auswählen Erweitern

filter:TYPE=MQTT2_DEVICE:FILTER=CID=ebus.* eigentlich gut gehen. Dann "siehst" du das template nicht in der Auswahlliste für anderes, z.B. tasmota-MQTT2-Geräte.

Neben group gibt es auch noch ein Attribut, um die sortby zu beeinflussen .

[Beta-User]

Neben group gibt es auch noch ein Attribut, um die sortby zu beeinflussen .

Hallo Reinhart,

habe eben auf dem Testsystem "ein bißchen umgeräumt"; ist eher wieder als Machbarkeitsstudie gedacht (Raum mit Unterräumen, mehere Geräte in einer group, geordnet mit sortby).
Muß man nicht so machen, aber es ist einfacher, die jeweilige Funktion zu verstehen, wenn man das schlicht mal "live" gesehen hat.

Was pah-Color angeht: Hast du da noch irgendwas optimiert bezüglich des "Mittelpunkts" (oder was auch immer dieser Parameter genau ist)?

[rudolfkoenig]

War also eine echt klasse Idee von Dir mit diesem feature und den ganzen "Arbeiten drumrum"!

Danke fuer die Blumen, aber mAn wird es nur deswegen so breit verwendet, weil Du und einige andere so viel Energie reinsteckt.
Und da es breit verwendet wird, lohnt sich auch meinerseits weiterhin Arbeit in das Framework reinzustecken.

[Beta-User]

@Reinhart und TomLee:
- Ein farewell für das "zentrale" ebus-template wäre m.E. eine gute Sache
- Ich würde da gerne ein "set <device> getAllBusDevices" einbauen oder zumindest einen einmaligen publish am Ende des templates. Könnte jamand mal auf john30 zugehen, ob es mqtt-seitig eine Möglichkeit gibt, eine Art "Präsentation" aller vorhandenen Busteilnehmer (oder gleich Readings) anzustoßen (das muß ggf. ebusd-seitig implementiert werden...)
- M.E. spräche nichts dagegen, die filter-Option zu nutzen und alle ebus-templates auch direkt via svn auszuliefern. Will nicht einer von euch den Maintainer dazu machen? (ich kann gerne weiter unterstützen).

Danke fuer die Blumen, aber mAn wird es nur deswegen so breit verwendet, weil Du und einige andere so viel Energie reinsteckt.
Und da es breit verwendet wird, lohnt sich auch meinerseits weiterhin Arbeit in das Framework reinzustecken.

...bedingt sich gegenseitig. Hätte nicht die Energie gehabt, wenn das MQTT2-framework nicht so flexibel wäre; es ist m.E. sehr wichtig, das das FHEM-seitig sehr gut unterstützt wird, einfach weil der "Zug" sehr stark in diese Richtung (auch) geht. Und den Trend @MQTT-"classic" empfand ich nicht als besonders zielführend, da für jede Sonderlocke ein eigenes Modul zu haben, (z.B. ich mit dem MiLight-Ding), nur um den Umgang mit JSON für das jeweilige Endgerät passend zu haben, und das ganze mit passenden Atrtributen "aufzuhübschen"...

So ist es viel besser .


[Eine OT-Bitte:]
Ich würde gerne attrTemplate auch bei MySensors zum Einsatz bringen, um damit die bei https://www.mysensors.org/build aufgeführten Beispiele aufzuhübschen.
Allerdings scheitere ich daran, die setExtensions wieder (?) zum laufen zu bringen - MySensors "tickt" da eher wie die mehrkanaligen Tasmota-Geräte, mal schaltet also eher ein Reading wie das Gerät. Das Manko kann man mit ReadingsProxy beseitigen (auch wenn mir die direkte Implementierung lieber wäre), aber attrTemplate läuft eben auch nicht.
Du hattest zwar mal irgendwo geschrieben, wie das mit AttrTemplate "solo" geht, aber ich müßte es a) suchen und b) hatte ich es zumindest damals nicht so einfach gefunden, dass ich es hätte umsetzen können. Vielleicht hast du Gelegenheit, mir auch da schnell "aufs Pferd" zu helfen ?

Ich hatte zu setExtensions hier mal einen Thread aufgemacht, das wäre ggf. passende die Stelle, wenn du was dazu antworten möchtest, ansonsten wurstel ich mich halt bei Gelegenheit selbst durch die Angelegenheit...

[Patrick131184]

Hallo zusammen,
ich bin gertade dabei mich mit den MQTT Templates zu beschäftigen. Leider bekomme ich das "E_05_eBus_Calormatic_readingsgroup_Set_Hcurve_Hotwater" template nichit ans laufen.

Beim anlegen aus meinem "MQTT2_ebusd_700" device sagt er immer

Code Auswählen Erweitern

eBusSet: unknown attribute model. Type 'attr eBusSet ?' for a detailed list.

Desweiteren kommt die Fehlermeldung beim setzen der Werte.

Code Auswählen Erweitern

Unknown argument Hc1HeatCurve_0_value, choose one of
attrTemplate:?,0_00_General_Info,A_00_MQTT2_CLIENT_general_bridge,A_01_tasmota_basic,A_01a_tasmota_basic_state_power1,A_10_shelly1,E_00_eBus_daemon_splitter,E_01_eBus_bai_readingsgroup_Status01,E_01a_eBus_daemon_splitter,E_02_eBus_bai_readingsgroup_Status01_Balken,E_03_eBus_bai_readingsgroup_Status02,E_03c_eBus_Hc1HeatCurve+HwcTempDesired_manualadd,E_04_eBus_bai_readingsgroup_Status02_Balken,E_05_eBus_Calormatic_readingsgroup_Set_Hcurve_Hotwater,E_06_eBus_bai_Status01,E_07_eBus_bai_Status01+Status02_HWC,E_08_eBus_SetMode,E_09_eBus_Hc1HeatCurve+HwcTempDesired,L_01_zigbee2mqtt_bridge,X_01_esp_milight_hub_bridge

Das Template E_03c_eBus_Hc1HeatCurve+HwcTempDesired funktioniert.

Kann mir hier jemand einen Denkanstoß zukommen lassen?

Hier der Code

Code Auswählen Erweitern

defmod eBusSet readingsGroup <>,<Name>,<&nbsp;;Ist>,<&nbsp;;&nbsp;;&nbsp;;&nbsp;;&nbsp;;&nbsp;;Soll>\
MQTT2_ebusd_700:<%message_tendency_steady>,<Heizkurve>,Hc1HeatCurve_0_value,<sollcurve>\
MQTT2_ebusd_700:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_tempv_value,<sollwater>
attr eBusSet commands {'eBusSet.sollcurve'=>'Hc1HeatCurve_0_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70',\
    'eBusSet.sollwater'=>'HwcTempDesired_tempv_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0'}
attr eBusSet nameStyle style="color:yellow"
attr eBusSet room eBus
attr eBusSet valueStyle {'Hc1HeatCurve_0_value' => '{"style=\"color:\x23".substr(Color::pahColor(0.1,1.0,1.5,$VALUE,0),0,6)."\""}',\
'HwcTempDesired_tempv_value' => '{"style=\"color:\x23".substr(Color::pahColor(0.1,1.0,1.5,$VALUE,0),0,6)."\""}'}




Vielen Dank!

[Beta-User]

Hmm, ich gehe mal davon aus, dass - wie der Name sagt - eine readingsGroup erstellt wird. Die kennt das Attribut "model" nicht, daher die Fehlermeldung.

Schreib' einfach ein "#" an den Anfang der betreffenden Zeile, dann sollte das gehen. (da geht nichts kaputt bei, danach die templates neu laden mit "{ AttrTemplate_Initialize() }".)

[Patrick131184]

Das Anlegen der ReadingGroup funktioniert auch. Aber das setzen der Werte halt nicht.

Wollte nur dabei schreiben, dass beim anlegen die Fehlermeldung mit dem model kommt.

Beim setzen der Werte nach wie vor

Code Auswählen Erweitern

Unknown argument Hc1HeatCurve_0_value, choose one of
attrTemplate:?,0_00_General_Info,A_00_MQTT2_CLIENT_general_bridge,A_01_tasmota_basic,A_01a_tasmota_basic_state_power1,A_10_shelly1,E_00_eBus_daemon_splitter,E_01_eBus_bai_readingsgroup_Status01,E_01a_eBus_daemon_splitter,E_02_eBus_bai_readingsgroup_Status01_Balken,E_03_eBus_bai_readingsgroup_Status02,E_03c_eBus_Hc1HeatCurve+HwcTempDesired_manualadd,E_04_eBus_bai_readingsgroup_Status02_Balken,E_05_eBus_Calormatic_readingsgroup_Set_Hcurve_Hotwater,E_06_eBus_bai_Status01,E_07_eBus_bai_Status01+Status02_HWC,E_08_eBus_SetMode,E_09_eBus_Hc1HeatCurve+HwcTempDesired,L_01_zigbee2mqtt_bridge,X_01_esp_milight_hub_bridge

[Reinhart]

@Patrick131184

kannst du mal bitte ein List von deinem 700er Device ( MQTT2_ebusd_700 ) hier posten welches von "autocreate" angelegt wurde?
Laut Csv nennt sich die Heizkurve bei der 700 auch so, sollte daher kein Problem sein.

Code Auswählen Erweitern

r;w,,Hc1HeatCurve,HeatCurve Heizkreis 1,,,,0F00,,,EXP,,,heating curve of Hc1

In den Templates gab es noch mehre kleine Fehler die ich in der Zwischenzeit behoben habe, diese waren aber hauptsächlich beim setzen der Farben weil hier nur Integer erlaubt ist. Hast du auch wirklich explizit das Schreiben in der Config ( /etc/default/ebusd ) erlaubt?

Code Auswählen Erweitern

--accesslevel=*

Im Augenblick wird noch viel an den (eBus) Templates gearbeitet und ich poste in den nächsten Tagen eine erweiterte und korrigierte Version.
Aber es ist schön wenn weitere Anwender hier Rückmeldung machen, vor allem mit Devices die wir nicht zum Test zur Verfügung haben und da ist die 700er willkommen!

Teste bitte mit der hier angehängten Version.

LG
Reinhart

[Reinhart]

hm, habe gerade gesehen, hier steht "...tempv_value", hast du das geändert oder ist das im Template ein Schreibfehler? Es sollte ...temp1_value" heißen.

Code Auswählen Erweitern

MQTT2_ebusd_700:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_tempv_value,<sollwater>
Aber das List wird das aufklären und außerdem gilt das für das Warmwasser und nicht für die Heizkurve.

LG

[Reinhart]

@Reinhart und TomLee:
- Ich würde da gerne ein "set <device> getAllBusDevices" einbauen oder zumindest einen einmaligen publish am Ende des templates. Könnte jamand mal auf john30 zugehen, ob es mqtt-seitig eine Möglichkeit gibt, eine Art "Präsentation" aller vorhandenen Busteilnehmer (oder gleich Readings) anzustoßen (das muß ggf. ebusd-seitig implementiert werden...)

Das ist nicht so einfach zu realisieren, weil das wirklich eine echte Busanfrage wäre. Man kann direkt in der Konsole das Kommando "ebusctl f" absetzen, welches dann alle Readings von geladenen CSV zurück gibt. "no data stored" bedeutet, hier ist noch kein Wert vorhanden, also noch nie abgefragt oder über den Bus gekommen. Ich glaube, uns wäre ja schon geholfen wenn wir dieses Kommando per MQTT String abfragen könnten. Per ECMD habe ich diese Information schon abgeholt und weiter verarbeitet.

Code Auswählen Erweitern

set search_activ cmd {"find -d\n"}
set search_activ expect ".*\n*"
set search_activ postproc { s_ebus($_); }

Ich werde mich aber mit John in Verbindung setzen was der für Möglichkeiten für dieses Feature sieht!
Aber eines ist klar, alle Messwerte jetzt über den Bus zu holen wäre Selbstmord für das Heizgerät. Der eBus ist leider kein TCPIP, hier läuft alles über feste Zeitfenster, was ja im Prinzip auch von TCPIP so umgesetzt wird aber halt viel schneller und flexibler. Die Master sind auch begrenzt und es bleibt noch das Problem der Speisung. Der eBus liefert ja auch die Versorgungsspannung und Low/High shiftet zwischen 9-24 V. Wenn ein einziges Gerät die Spezifikation nicht einhält ( zu schnell sendet, oder sendet wenn es nicht sollte ) wird das ganze Protokoll sehr wackelig und braucht eine Weile bis es wieder synchronisiert.

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl f
430 ACTOstorDetected = no data stored
430 actoSTOROPMode = no data stored
430 actostorstate = no data stored
430 ActualRoomTempDesiredHc1 = no data stored
430 ActualWeekday = no data stored
430 adpPreHActive = no data stored
430 adpPreHCurrentRoomTemp = no data stored
430 adpPreHInSideTW = no data stored
430 adpPreHMinutesBeforeFirstTW = no data stored
430 adpPreHOutdoorTemp = no data stored
430 adpPreHOutdoorTempStart = no data stored
430 adpPreHPreheatingTime = no data stored
430 adpPreHRamp = no data stored
430 adpPreHRoomTempDesired = no data stored
430 adpPreHRoomTempStart = no data stored
430 adpPreHStarttime = no data stored
430 AssertFileName = no data stored
430 AssertLineNumber = no data stored
430 AutoOffMode = no data stored
430 B50418actDesFlowTemp = no data stored
430 B51000FlowSetMonitor = no data stored
430 B51000M10HwcFlowSetMon = no data stored
430 B51000M12DisableBitsMon = no data stored
430 B51000M14Monitor = no data stored
430 B51000M7OpModeMonitor = no data stored
430 B51000TempDesiredLoadingPump = no data stored
430 BaseDisplay = no data stored
430 BMUB51101BoilerFlowTemp = no data stored
430 BMUB51101ErrorStatus = no data stored
430 BMUB51101HwcState = no data stored
430 BMUB51101StorageTemp = no data stored
430 BMUFlowTempOrVF1 = no data stored
430 CalculatedKickStopTime = no data stored
430 ccTimer.Friday = no data stored
430 ccTimer.Monday = no data stored
430 ccTimer.Saturday = no data stored
430 ccTimer.Sunday = no data stored
430 ccTimer.Thursday = no data stored
430 ccTimer.Tuesday = no data stored
430 ccTimer.Wednesday = no data stored
430 ChimneySweepModeActive = no data stored
430 CirPump = no data stored
430 ContinuosHeating = no data stored
430 CountryVariant = no data stored
430 CPLPLast24started = no data stored
430 currenterror = no data stored
430 Date = no data stored
430 DisplayedHc1RoomTempDesired = no data stored
430 DisplayedHwcStorageTemp = no data stored
430 DisplayedRoomTemp = no data stored
430 EepromUpdateActive = no data stored
430 EnermanState = no data stored
430 errorhistory = no data stored
430 ExcessTemp = no data stored
430 FrostOverRideTime = no data stored
430 FrostProtectDelayMonitor = no data stored
430 FrostProtectionRequiredMonitor = no data stored
430 FrostProtectStateMonitor = no data stored
430 Hc1ActualFlowTempDesired = no data stored
430 Hc1HcType = no data stored
430 Hc1HeatCurve = 1.20
430 Hc1ManualOPRoomTempDesired = no data stored
430 Hc1MinimalFlowTempDesired = no data stored
430 Hc1NightTemp = no data stored
430 Hc1OPMode = no data stored
430 Hc1PreOrContinuosHeatingActive = no data stored
430 Hc1Pump = no data stored
430 Hc1PumpLast24started = no data stored
430 Hc1QuickVetoActive = no data stored
430 Hc1QuickVetoTemp = no data stored
430 Hc1RoomTempSwitchOn = no data stored
430 Hc1SummerOffset = no data stored
430 Hc2HcType = no data stored
430 HcMc1ConfigCPLPAsLP = no data stored
430 HcMc1CPLPState = no data stored
430 HcMc1Detected = no data stored
430 hcTimer.Friday = no data stored
430 hcTimer.Monday = no data stored
430 hcTimer.Saturday = no data stored
430 hcTimer.Sunday = no data stored
430 hcTimer.Thursday = no data stored
430 hcTimer.Tuesday = no data stored
430 hcTimer.Wednesday = no data stored
430 HolidayEndPeriod = no data stored
430 HolidayRoomTemp = no data stored
430 HolidayStartPeriod = no data stored
430 HRUDetected = no data stored
430 HwcActualTempDesired = no data stored
430 HwcCircuitActive = no data stored
430 HwcLegioStartDay = no data stored
430 HwcLegioStartTime = no data stored
430 HwcLoadingIn430Active = no data stored
430 HwcLoadingInBMUActive = no data stored
430 HwcLoadingOffset = no data stored
430 HwcManualOPTempDesired = no data stored
430 HwcOPMode = no data stored
430 HwcParallelLoading = no data stored
430 HwcPressLowpostrunningtime = no data stored
430 HwcQuickVetoActive = no data stored
430 HwcQuickVetoTemp = no data stored
430 HwcTempDesired = 55.0
430 hwcTimer.Friday = no data stored
430 hwcTimer.Monday = no data stored
430 hwcTimer.Saturday = no data stored
430 hwcTimer.Sunday = no data stored
430 hwcTimer.Thursday = no data stored
430 hwcTimer.Tuesday = no data stored
430 hwcTimer.Wednesday = no data stored
430 IsInHoliday = no data stored
430 KeyCodeforConfigMenu = no data stored
430 LcdContrastValue = no data stored
430 LegioProtectActive = no data stored
430 MaintenanceDate = no data stored
430 MonitorEEpromInkonsiNumber = no data stored
430 NameHc1 = no data stored
430 NameHc2 = no data stored
430 NameHwc = no data stored
430 OutsideTemp = no data stored
430 OutsideTempOffset = no data stored
430 PhoneNumber1 = no data stored
430 PhoneNumber2 = no data stored
430 PreheatingTime = no data stored
430 PreStopTime = no data stored
430 PumpBlockingTimeMax = no data stored
430 PumpEnergySaveCalculatedTimeMonitor = no data stored
430 PumpEnergySaveStateMonitor = no data stored
430 RoomTemp = no data stored
430 RoomTempCorrection = no data stored
430 RoomTempOffsetSelfWarming = no data stored
430 Setpoints.Friday = no data stored
430 Setpoints.Monday = no data stored
430 Setpoints.Saturday = no data stored
430 Setpoints.Sunday = no data stored
430 Setpoints.Thursday = no data stored
430 Setpoints.Tuesday = no data stored
430 Setpoints.Wednesday = no data stored
430 SolModuleDetected = no data stored
430 StartEepromUpdate = no data stored
430 StatusDcf = no data stored
430 SummerWinterTimeAdjust = no data stored
430 Time = no data stored
430 V430PluggedIn = no data stored
430 VF1 = no data stored
bai AATemp = no data stored
bai AccessoriesOne = no data stored
bai AccessoriesTwo = no data stored
bai ACRoomthermostat = no data stored
bai AircontrolOk = no data stored
bai AITemp = no data stored
bai AntiCondensValue = no data stored
bai averageIgnitiontime = no data stored
bai BlockTimeHcMax = no data stored
bai BoilerType2 = no data stored
bai BoilerType = no data stored
bai ChangesDSN = no data stored
bai CirPump = no data stored
bai CounterStartattempts1 = 29
bai CounterStartattempts2 = no data stored
bai CounterStartAttempts3 = no data stored
bai currenterror = no data stored
bai DateTime = nosignal;12:47:13;-.-.-;6.688
bai dcfState = no data stored
bai DCFTimeDate = no data stored
bai DCRoomthermostat = no data stored
bai DeactivationsIFC = 18
bai DeactivationsTemplimiter = no data stored
bai DeltaFlowReturnMax = no data stored
bai DisplayMode = no data stored
bai DSN = no data stored
bai DSNOffset = no data stored
bai DSNStart = no data stored
bai EBusHeatcontrol = no data stored
bai EbusSourceOn = no data stored
bai EbusVoltage = no data stored
bai errorhistory = no data stored
bai ExhaustCurve = no data stored
bai exhaustWayBlockCounter = no data stored
bai expertlevel_ReturnTemp = no data stored
bai ExternalFaultmessage = no data stored
bai externalFlowTempDesired = no data stored
bai externalHwcSwitch = no data stored
bai ExternGasvalve = no data stored
bai ExtFlowTempDesiredMin = no data stored
bai extWP = no data stored
bai FanHours = 6265
bai FanMaxSpeedOperation = no data stored
bai FanMinSpeedOperation = no data stored
bai FanPWMSum = no data stored
bai FanPWMTest = no data stored
bai FanSpeed = 1780
bai FanStarts = no data stored
bai Flame = no data stored
bai FlameSensingASIC = no data stored
bai FloorHeatingContact = no data stored
bai FlowsetHcMax = no data stored
bai FlowsetHwcMax = no data stored
bai FlowSetPotmeter = no data stored
bai FlowTemp = 47.19;ok
bai FlowTempDesired = 44.50
bai Fluegasvalve = no data stored
bai Gasvalve3UC = no data stored
bai Gasvalve = no data stored
bai GasvalveASICFeedback = no data stored
bai GasvalveUC = no data stored
bai GasvalveUCFeedback = no data stored
bai GVStepOffsetMax = no data stored
bai GVStepOffsetMin = no data stored
bai HcHours = 5366
bai HcPumpMode = no data stored
bai HcPumpStarts = no data stored
bai HcStarts = 39100
bai HcUnderHundredStarts = no data stored
bai HeatingSwitch = no data stored
bai HoursTillService = no data stored
bai HwcDemand = no data stored
bai HwcHours = 677
bai HwcImpellorSwitch = no data stored
bai HwcPostrunTime = no data stored
bai HwcSetPotmeter = 54.38
bai HwcStarts = 87400
bai HwcSwitch = no data stored
bai HwcTemp = no data stored
bai HwcTempDesired = no data stored
bai HwcTempMax = no data stored
bai HwcTypes = no data stored
bai HwcUnderHundredStarts = no data stored
bai HwcWaterflow = no data stored
bai HwcWaterflowMax = no data stored
bai Ignitor = no data stored
bai IonisationVoltageLevel = no data stored
bai maintenancedata_HwcTempMax = no data stored
bai maxIgnitiontime = no data stored
bai minIgnitiontime = no data stored
bai ModulationTempDesired = no data stored
bai OutdoorstempSensor = 6.69;ok
bai OverflowCounter = no data stored
bai ParamToken = no data stored
bai PartloadHcKW = 18
bai PartloadHwcKW = no data stored
bai PartnumberBox = no data stored
bai PositionValveSet = no data stored
bai PowerValue = no data stored
bai PrAPSCounter = no data stored
bai PrAPSSum = no data stored
bai PredCombustionDecrementTime = no data stored
bai PredCombustionPredCounter = no data stored
bai PredCombustionSwitchingPoint = no data stored
bai PredFanPWMDevThreshold = no data stored
bai PredFanPWMPredCounter = no data stored
bai PredFanPWMRefPWMcounter = no data stored
bai PredFanPWMRefPWMsum = no data stored
bai PredFanPWMSwitchingPoint = no data stored
bai PredIgnitionPredCounter = no data stored
bai PredIgnitionSwitchingPoint = no data stored
bai PredSourcePressureDevThreshold = no data stored
bai PredSourcePressurePredCounter = no data stored
bai PredSourcePressureSwitchingPoint = no data stored
bai PredWaterflowDevThreshold = no data stored
bai PredWaterflowSwitchingPoint = no data stored
bai PredWaterpressureMaxPressure = no data stored
bai PredWaterpressureMinPressure = no data stored
bai PredWaterpressureSwitchingPoint = no data stored
bai PrEnergyCountHc1 = no data stored
bai PrEnergyCountHc2 = no data stored
bai PrEnergyCountHc3 = no data stored
bai PrEnergyCountHwc1 = no data stored
bai PrEnergyCountHwc2 = no data stored
bai PrEnergyCountHwc3 = no data stored
bai PrEnergySumHc1 = no data stored
bai PrEnergySumHc2 = no data stored
bai PrEnergySumHc3 = no data stored
bai PrEnergySumHwc1 = no data stored
bai PrEnergySumHwc2 = no data stored
bai PrEnergySumHwc3 = no data stored
bai PumpHours = no data stored
bai PumpHwcFlowNumber = no data stored
bai PumpHwcFlowSum = no data stored
bai ReduceModulationBlocktime = no data stored
bai RemainingBoilerblocktime = no data stored
bai ReturnRegulation = no data stored
bai ReturnTemp = 38.69;64916;ok
bai ReturnTempMax = no data stored
bai SecondPumpMode = no data stored
bai SerialNumber = no data stored
bai SetFactoryValues = no data stored
bai SetMode = auto;44.5;-;-;0;0;1;0;0;0
bai SHEMaxDeltaHwcFlow = no data stored
bai SHEMaxFlowTemp = no data stored
bai SolPostHeat = no data stored
bai SpecialAdj = no data stored
bai Statenumber = no data stored
bai Status01 = 47.0;38.0;6.688;33.0;38.0;on
bai Status02 = auto;60;70.0;70;54.0
bai Status16 = no data stored
bai Status = no data stored
bai Storageloadpump = no data stored
bai StorageLoadPumpHours = no data stored
bai StorageloadPumpStarts = no data stored
bai StorageLoadTimeMax = no data stored
bai StoragereleaseClock = no data stored
bai StorageTemp = no data stored
bai StorageTempDesired = no data stored
bai StorageTempMax = no data stored
bai TargetFanSpeed = no data stored
bai TargetFanSpeedOutput = no data stored
bai TempDiffBlock = no data stored
bai TempDiffFailure = no data stored
bai TempGradientFailure = no data stored
bai Templimiter = no data stored
bai TemplimiterWithNTC = no data stored
bai TempMaxDiffExtTFT = no data stored
bai TimerInputHc = no data stored
bai ValveMode = no data stored
bai ValveStarts = no data stored
bai VolatileLockout = no data stored
bai WarmstartDemand = no data stored
bai WarmstartOffset = no data stored
bai WaterHcFlowMax = no data stored
bai WaterPressure = 1.993;ok
bai WaterpressureBranchControlOff = no data stored
bai WaterpressureMeasureCounter = no data stored
bai WaterpressureVariantSum = no data stored
bai WP = no data stored
bai WPPostrunTime = no data stored
bai WPPWMPower = 53
bai WPPWMPowerDia = no data stored
bai WPSecondStage = no data stored
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = 4.688
broadcast signoflife = no data stored
broadcast vdatetime = 09:25:06;25.03.2019
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.05  = no data stored
scan.06  = no data stored
scan.08  = Vaillant;BAI00;0518;7401
scan.08 id = ;;;;;;
scan.15  = Vaillant;43000;0215;2002
scan.15 id = 21;11;09;0020028515;0907;006374;N5
scan.36  = no data stored

Ergebnis von "ebusctl f"

LG
Reinhart

[Beta-User]

Hmm,

im Prinzip würde die Rückgabe aus dem CSV schon hilfreich, aber wenn, sollte man die Rückmeldung@MQTT dann auf die Datenfelder beschränken, die tatsächlich Daten enthalten.

Dann wäre es m.E. eine super Sache. Vermutlich wäre das auch nicht besonders schwierig zu realisieren, die Daten scheinen im ebus-Dämon ja vorhanden zu sein; der muß sie nur - in einer bezgl. MQTT sinnvollen Art und Weise - rausrücken. Dabei wäre es klasse, wenn die Daten dann schon auf dem "normalen" Weg in der Topicstruktur übertragen würden, also genau so, wie wenn man das aktiv anfragt.

MQTT-mäßig wäre das eigentlich diese "ebusd/+/+/get"-Anfrage (also liefere die _vorhandenen_ Daten auf einem bestimmten Teil der Topic-Struktur). Ins Unreine: Vielleicht kann man das so machen, dass ebusd/+/+ die vorhandenen Daten OHNE Bus-Abfrage liefert (also ohne das Heizgerät aus dem Tritt zu bringen) und nur der Zusatz "get" dann erst die Abfrage auch auf den Bus schickt (aber nur für bekannt belegte Felder). Wenn Busseitig sinnvoll, könnte man das get dann auf Einzel-Abfragen beschränken, also keine wildcards zulassen?