Hallo,
mit Reinharts Beispiel-Templates hatte ich vor 2 Wochen gespielt und konnte auch die WW-Temperatur setzen.
Jetzt versuche ich das in meinem u.a. Device umzusetzen, das temp1_value wie in Reinharts Beispiel mein ich ist bei mir das
SetMode_hwctempdesired_value, das setzen klappt aber nicht.
Kann mir da wer weiterhelfen ?
Zitatdefmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
attr MQTT2_Test_Ebusd devStateStyle style="text-align:right"
attr MQTT2_Test_Ebusd event-on-change-reading .*
attr MQTT2_Test_Ebusd icon icoTempHeizung
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:1_Vorlauf Status01_0_name:0 Status01_1_value:1_Ruecklauf Status01_1_name:0 Status01_2_value:1_OutdoorstempSensor Status01_2_name:0 Status01_3_value:Fragez Status01_3_name:0 Status01_4_value:1_HwctempSensor Status01_4_name:0 Status01_5_value:1_Pumpe Status01_5_name:0 WaterPressure_press_value:WaterPressure WaterPressure_sensor_value:0 FlowTempDesired_temp_value:FlowTempDesired CirPump_onoff_value:CirPump Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:HeatCurve z1DayTemp_tempv_value:z1DayTemp
attr MQTT2_Test_Ebusd model E_04a_eBus_Test_Status01+SetMode+WaterPressure+CirPump+Hc1HeatCurve+z1DayTemp
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }
attr MQTT2_Test_Ebusd setList SetMode_hwctempdesired_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/bai/HwcTempDesired/set $EVTPART1
attr MQTT2_Test_Ebusd stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>WW-Temperatur: %.1f <br>Aussentemperatur.: %.1f <br>Pumpe: %s <br>Fragez: %.1f <br>Druck: %.1f <br>WW-Set: %s <br>Zirk.pumpe: %s", ReadingsVal($name,"1_Vorlauf",0), ReadingsVal($name,"1_Ruecklauf",0), ReadingsVal($name,"1_HwctempSensor",0),ReadingsVal($name,"1_OutdoorstempSensor",0), ReadingsVal($name,"1_Pumpe",0), ReadingsVal($name,"Fragez",0), ReadingsVal($name,"WaterPressure",0), ReadingsVal($name,"FlowTempDesired",0), ReadingsVal($name,"CirPump",0))}
attr MQTT2_Test_Ebusd webCmd SetMode_hwctempdesired_value
attr MQTT2_Test_Ebusd webCmdLabel WW-Set
setstate MQTT2_Test_Ebusd Vorlauf: 66.0 <br>Ruecklauf: 0.0 <br>WW-Temperatur: 51.0 <br>Aussentemperatur.: 20.4 <br>Pumpe: off <br>Fragez: 0.0 <br>Druck: 2.4 <br>WW-Set: 0 <br>Zirk.pumpe: off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_HwctempSensor 51.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_OutdoorstempSensor 20.438
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_Pumpe off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 1_Vorlauf 66.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:42 CirPump off
setstate MQTT2_Test_Ebusd 2019-02-28 16:33:26 Fragez 0.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 HeatCurve 2.05
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehc_value 1
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehwcload_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_disablehwctapping_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_flowtempdesired_value 0.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_hcmode_value auto
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_hwctempdesired_value 55.0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_releaseBackup_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_releaseCooling_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 SetMode_remoteControlHcPump_value 0
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 WaterPressure 2.372
setstate MQTT2_Test_Ebusd 2019-02-28 16:32:41 z1DayTemp 22
Gruß
Thomas
Hi Thomas,
leider habe ich nicht die große Ahnung vom ebusd und von den templates dafür, würde aber gerne auch ein oder zwei Beispiele aus eurem template-file in die allgemeinen Templates übernehmen; der ebusd scheint im Moment der einzige Fall zu sein, bei dem das JSONMAP seine volle Wirkung zeigen kann :) .
Vielleicht vorab zwei Dinge:
- ich verstehe nicht ganz, für was die bridgeRegexp in dem ebus-Device sinnvoll ist. M.E. macht eine solche zwar großen Sinn, wenn man einen externen Broker nutzt, aber dann als separates Device (ein template dafür habe ich vor nicht allzu langer Zeit aufgenommen und die Praxisbeispiele entsprechend ergänzt. Das ist m.E. aber gar nicht erforderlich, wenn man den MQTT2_SERVER nutzt und sollte daher nicht Teil eines Geräts oder templates für ebusd sein).
Vorschlag (bitte config vorher mal zur Sicherheit als Kopie wegspeichern): Ein beliebiges MQTT2_DEVICE kopieren, und auf das dann das allg. Bridge-template anwenden (für Nutzer des MQTT2_CLIENT). Und dann diesen Teil aus dem ebusd-Gerät entfernen.
- v.a. wenn einzelne Dinge nicht erwartungsgemäß funktionieren, macht es m.E. immer Sinn, die Optionen im IO-Device zu nutzen.
Konkret hieße das hier:
-- An deinem MQTT2_CLIENT-Gerät das rawEvents-Attribut setzen und dann mal den Verkehr in einem separaten EVENT-Monitor mit Begrenzung auf dieses IO beobachten.
-- Darüber kann man dann auch den set-Befehl mit einem direkten publish mal testen. Geht der raus wie gedacht, hat aber keine Auswirkung, liegt es entweder am Zielgerät, dem Übertragungsweg dahin oder der Syntax. Damit würde ich hier mal anfangen.
Dann hätte ich noch eine Bitte: der ebusd-Thread ist ziemlich unübersichtlich. Ist das template von Reinhart in seinem ersten Thread jetzt eigentlich die beste Basis, oder hast du da noch weitere Anpassungen gemacht, die du gut findest?
Zunächst wäre es hilfreich, wenn wir eine Art Basis-Template hätten, das für alle Arten von ebusd-Nutzern hilfreich sein könnte.
Hoffe, das hilft erst mal weiter und ist (halbwegs) versändlich geschrieben.
Gruß, Beta-User
Zunächst einmal danke das uns Beta-User seine Unterstützung zur Entwicklung von eBus Templates anbietet! Er hat auch schnell erkannt, das der eBus die ideale Spielwiese für diese von Rudi entwickelte Technologie ist.
Ich habe ja vor einigen Woche dieses Beispiel-Template in den eBus Thread gestellt und gehofft das Thema MQTT2 etwas zu forcieren weil ich glaube das MQTT generell hohes Potential hat. Was bei ESP8266 schon lange Standard ist kann auch eBusd schon lange, John hat dafür schon vorgesorgt. Mir ist schon klar, das gerade Neueinsteiger lieber alte Wiki Einträge benutzen als sich jetzt auch noch mit MQTT oder gar Mosquitto auseinander zu setzen. Wieder was installieren, ohjeh!
Aber eigentlich ist es das Gegenteil, hoher Komfort wie ihn sonst nur GAEBUS bietet ist damit möglich und das mit einem Protokoll das von vielen SmartHome Umgebungen gesprochen wir.
Aber ich glaube wir sollten bevor wir die Unterstützung von Beta-User benutzen wollen, zunächst das Ziel von eBusd Templates festlegen zu versuchen. Ich habe ja bei den ersten Beispielen bewusst nur jene Datenpunkte ausgewählt, wo ich glaube das diese Datenpunkte bei einer großen Anzahl von Geräten vorkommen.
Beispiel: wer nur ein Brennwertgerät hat wird auch keine Heizkurve setzen können. Wer eine reine Therme hat wird auch keinen Warmwasserkessel haben. Daher ergeben sich aus solchen Vorgaben schon die Art der einzeln benötigten Templates.
Ich finde wir sollten daher zuerst eine Art Bestandsaufnahme durchführen um überhaupt die Art und Menge der benötigten Templates einmal grob zu definieren. Bei den Templates geht es ja in erster Linie um die Ausgabe (printf) am Display und die kann sich aus verschiedenen Variablen zusammen setzen. Je mehr Variablen und mehr Automatismus enthalten ist, desto vielfältiger läßt sich so ein Template dann einsetzen.
Schön wäre ohnehin ein einziges Template das alles kann, doch wer will einen Wulst von Daten in einem Reading? Dann doch lieber eine Unterteilung die logisch Sinn macht und darüber sollten wir uns hier abstimmen zu versuchen.
Dazu ist natürlich die Mitarbeit von möglichst vielen Anwendern gefragt, jeder hat andere Wünsche oder Ideen.
Ich stelle daher einmal die generelle Frage, sollten wir die Templates nach dem Typ der Datenpunkte (Warmwasser, Heizkurve, Datum, Zeit etc.) oder eher nach der Art der Heizgeräte Hardware (zB: Calormatic, 430, 470, 350) unterteilen.
@TommLee
so richtig verstehe ich dein Problem nicht warum das nicht funktionieren sollte.
#ebus Hcurve+HwcTempDesired Messages.
name:E_03c_eBus_Hc1HeatCurve+HwcTempDesired
filter:TYPE=MQTT2_DEVICE
par:BASE_DEV;base topic set in config;{ AttrVal("DEVICE","readingList","") =~ m,ebusd/([^/]*)/, ? $1 : undef }
desc:Applies settings to ebus Heatingcurve and Hotwater
attr DEVICE icon message_tendency_steady
attr DEVICE webCmd curve_value:temp1_value
attr DEVICE webCmdLabel Hc1HeatCurve:HwcTempDesired
attr DEVICE setList\
curve_value:0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/BASE_DEV/Hc1HeatCurve/set $EVTPART1\
temp1_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/BASE_DEV/HwcTempDesired/set $EVTPART1
deletereading DEVICE .*
Ich habe ja im Template "E_03c_eBus_Hc1HeatCurve+HwcTempDesired" auch schon die HwcTempdesired verwendet und die funktioniert bei meiner HW und läßt sich setzen. Du hast sicher schon auf Command Ebene den Befehl getestet ob er auch bei deiner Umgebung funktioniert.
Zuerst mit "ebusctl" und dann mit Mosquitto in der Befehlszeile. Nur so kann ich schnell feststellen wo ein Fehler herkommt.
LG
Reinhart
Zitat von: Beta-User am 28 Februar 2019, 17:35:00
- ich verstehe nicht ganz, für was die bridgeRegexp in dem ebus-Device sinnvoll ist.
das kommt von solchen Json Strings, hier eine typische Statusmeldung wie sie als als Broadcast ankommt.
Client mosqsub/3355-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status01', ... (271 bytes))
ebusd/bai/Status01 {
"0": {"name": "temp1", "value": 23.0},
"1": {"name": "temp1", "value": 23.0},
"2": {"name": "temp2", "value": 9.250},
"3": {"name": "temp1", "value": 25.0},
"4": {"name": "temp1", "value": 26.0},
"5": {"name": "pumpstate", "value": "off"}}
Die Regexp zerlegt uns nun in "0_name" und "0_value". Und genau hier ist das Problem warum wir auch JSONMAP benötigen, weil Status02 macht gleiche Namen.
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }Client mosqsub/3355-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status02', ... (221 bytes))
ebusd/bai/Status02 {
"0": {"name": "hwcmode", "value": "auto"},
"1": {"name": "temp0", "value": 60},
"2": {"name": "temp1", "value": 70.0},
"3": {"name": "temp0", "value": 70},
"4": {"name": "temp1", "value": 54.0}}
LG
Guten Morgen zusammen,
@Reinhart vorab: Danke für die Vorschußlorbeeren...
Gleich auch ein paar Anmerkungen:
Zitat von: Reinhart am 28 Februar 2019, 22:05:37
das kommt von solchen Json Strings, hier eine typische Statusmeldung wie sie als als Broadcast ankommt.
Da würde ich dir gerne eine Wette dagegen anbieten, aber das wäre vermutlich unfair :D .
Bitte setzt mal den Vorschlag aus meinem ersten Post um und definiert ein allgemeines Bridge-Gerät. (Für später hinzugestoßene: Das gilt nur für user, die MQTT2_CLIENT als IO verwenden, für MQTT2_SERVER ist das nicht erforderlich. Allgemein: Wer neu in das Thema MQTT einsteigt, sollte direkt MQTT2_SERVER verwenden, das macht es m.E. einfacher, nicht nur in der Handhabung, auch in der Installation; man kann ggf. später umstellen, wenn man doch mosquitto oä. verwenden will).
Für das weitere brauchen wir vermutlich auch "Echtgeräte", allerdings sollte das die Funktionalität der bestehenden Definitionen möglichst nicht beeinträchtigen. Dazu würde ich vorschlagen, dass ihr dazu dann mind. zwei bzw. drei Geräte (defines) habt:
- (Nur MQTT2_CLIENT: eines, auf das A_00_MQTT2_CLIENT_general_bridge angewendet wurde - da würde mich eh' interessieren, ob das funktioniert wie erwartet)
- ein "unangetastetes" Normalgerät für den regulären Betrieb, in das ggf. dann Verbesserungen manuell eingepflegt werden;
- eines zum "Spielen" mit den templates. Da kann es sein, dass wir noch ein paar mehr brauchen...
Daraus ergeben sich leider ein paar Nebenwirkungen, die man im Auge haben sollte: Vorhandene Readings werden zwar in allen MQTT2_DEVICE-Geräten aktualisiert, wenn ein publish eingeht, autocreate wirkt aber ggf. nur auf eines ein - wenn jemand irgendwas bei einem bisher unbekanntem Topic in einer readingList "fehlt", sollte er also immer in allen Geräten nachsehen, wo es ggf. angelegt worden ist. Am "Normalgerät" sollte daher autocreate abgeschaltet werden.
Generell finde ich den Ansatz gut, ggf. erst mal einige wenige Grundtypen zu definieren und da in das template jeweils nur das reinzuschreiben, was auch mit einiger Sicherheit "da" sein wird.
Was mir zum Ganzen generell als Neuerung bei den attrTemplates im Kopf rumschwirrt, wäre ggf. die attrTemplate-Methode zu nutzen, um eine vorhandene readingList, setList oder JSONMAP zu _erweitern_. Das hat auch einen Nachteil: Es könnte zu Doppeleinträgen kommen. Da brauchen wir evtl. eine neue allgemeine Routine oder eine myUtils.pm, um da wieder für Ordnung zu sorgen. Von daher wäre es ggf. auch (später?) sinnvoll, das in den MQTT-Bereich zu verschieben, damit Rudi sich dazu eine Meinung bilden kann.
Weiterer Gedanke: Es wäre auch möglich, statt eines "Großdevices", das alle Readings enthält, auch Teile abzuspalten, und Funktionsgruppen separat darzustellen. Als logische Klammer könnten wir das Reading associatedWith nutzen, und in der Darstellung in FHEMWEB das Gruppen-Attribut, ggf. mit einer Sortierpriorität innerhalb der Gruppe. Konkret könnte das so aussehen, dass man ein template auf das "Stammdevice" anwendet, und das dann ein abgeleitetes Device mit den passenden Readings für eine Funktionsgruppe anlegt, das ganze im selben Raum wie das "Stammdevice", mit dem associatedWith-Reading zum Stammdevice und derselben Gruppenzugehörigkeit.
Dann hätte ich noch die Frage, ob es weitere "setter" geben sollte? Beispiel: ich habe eine Junkers (die leider nicht "ebus" spricht). Da nervt mich z.B. sehr, dass die dort verbaute Uhr so ungenau ist und die Zeitumstellung noch nicht kennt...
Das allererste, was ich der beibringen würde, wäre jeden Monat bzw. zu den Umstellungsdaten die aktuelle Zeit ;D . Ist doch bestimmt beim ebus möglich...
Zur JSONMAP: Wäre es evtl. sinnvoll, sich an die Terminologie zu halten, die der/die Hersteller auch in ihren Handbüchern verwenden? Dann sprecht ihr dieselbe Sprache wie eure Servicetechniker und Heizungsbauer ;) .
Was die Bereitstellung der templates und den Verbreitungsweg angeht, muß ich mir mal die Funktionalität des filter-Parameters ansehen. Evtl. wäre es möglich, die ebus-Templates nur mit anzuzeigen, wenn das Gerät, auf das der attrTemplate-?-Befehl angewendet wird, der devspec "model=E_03.*_eBus_.*" entspricht... Dann könnte man die file ohne weiteres größer machen bzw. eine ebus-spezifische template-file via svn ausliefern, ohne dass das den großen Rest irgendwie stört. Nur einmal ein ebus-Basistemplate drüber, schon erhält man Zugriff auf die anderen :) . (muß ich mir mal für tasmota... auch ansehen, das würde die Übersichtlichkeit insgesamt vielleicht erhöhen).
Apropos testen:
Um selbst irgendwas auszutesten, würde ich bei Gelegenheit mal ein paar RAW-Definitionen von ebus-Geräten benötigen, sonst habe ich nichts, wogegen ich template-Versuche laufen lassen kann. (am besten eine file, die ich direkt irgendwo wegspeichern kann).
Bitte fragt nach, wenn was nicht verständlich sein sollte, das waren jetzt sehr viele Dinge auf einmal, die auch bei mir noch nicht ausgereift sind.
Einen netten Tag wünscht euch
Beta-User
Zitat von: Beta-User am 01 März 2019, 08:00:37
Apropos testen:
Um selbst irgendwas auszutesten, würde ich bei Gelegenheit mal ein paar RAW-Definitionen von ebus-Geräten benötigen, sonst habe ich nichts, wogegen ich template-Versuche laufen lassen kann. (am besten eine file, die ich direkt irgendwo wegspeichern kann).
... das war jetzt viel, kann ich auf einmal gar nicht beantworten.
Wegen der Testumgebung hast PN von mir bekommen. Da kannst du alles testen was das Herz begehrt.
Beim Aufbau der Testumgebung habe ich viel mit dem MQTT2_Server getestet. Das wäre ja eine total einfach zu konfigurierende Sache. Er macht ja ohne Regexp schon sehr viel, aber halt leider mit dem Problem des überschreiben bei Namensgleichheit wenn kein Jsonmap gesetzt wird. Was ich da stark vermisse ist die Möglichkeit Templates anzuwenden oder muss man da dann zwingend auch die Bridge installieren?
Der Mosquitto ist zwar besser zum debuggen, aber auch das Log beim MQTT2_Server ist sehr aussagekräftig. So wie ich bis jetzt sehe, wäre das schon der richtige Weg und gleich von Start weg auf Mosquitto verzichten.
LG
Moin zusammen,
@TomLee:
Hattest du mal Gelegenheit, den direkten publish-Versuch zu testen? M.E. brauchst du damit nicht zu warten, bis template-mäßig was feststeht...
@Reinhart:
Danke für die Idee mit der Testumgebung, vermutlich kann ich mich irgendwann im Lauf des Tages da mal aufschalten.
Vorab hatte mich das aber schon mal motiviert, mich zum einen gedanklich mal mit den Unterschieden zwischen dem MQTT2_SERVER und MQTT2_CLIENT zu befassen, und da du jetzt schreibst, dass mit dem -er-Server alles viel einfacher war:
Wir packen als erstes das general-Client-template an ;) . Das sollte sich so verhalten wie der MQTT2-Server, indem es ebus-Infos und anderes sauber trennt. Also das erste bridgeRegep-Element so ändern, dass es _nicht_ auf ebus-Infos paßt und ein zweites dazu, dass alles an das ebus-Gerät weitergibt.
(und dann würde ich mal eine bridgeRegexp am ebus-Gerät testen, die alles, was nicht zum zentralen Steuergerät gehört auf eigene Geräte weiterverteilt).
Ins unreine gesprochen wäre es dann eventuell noch sehr hilfreich, wenn man mit "autocreate = 2" (oder so) dann autocreate anweisen könnte, die "extended version" von json2nameValue() zu verwenden. Ich hätte da noch weitere Ideen, aber da müssten wir ggf. erst mal noch testen, was da sinnvoll ist.
Anderer Punkt aus der pm: haben beide CLIENTs (Testsystem und Hauptsystem) unterschiedliche clientID-Werte per Attribut oder haben unterschiedliche Namen?
soviel mal vorab, bis später :) .
wenn du mit ClientID die CID meinst, ja die sind unterschiedlich.
Hauptsystem: CID ebusd_bai
Internals:
CID ebusd_bai
DEF ebusd_bai
DEVICETOPIC MQTT2_ebusd_bai
FUUID 5c65cd25-f33f-27bd-80dc-329a8ac7822ec5a5
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 45584
NAME MQTT2_ebusd_bai
NR 2824
STATE Vorlauf: 36.0 <br>Ruecklauf: 36.0 <br>Warmwasser: 36.0 <br>Aussentemp.: 5.1 <br>Pumpe: off <br>HWC-maxTemp: 60.0 <br>HWC-Regler_Max: 70.0 <br>HWC-CurrentTemp: 54.0 <br>HWC-Mode: auto
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 45584
ebusMQTT_TIME 2019-03-02 09:36:17
Helper:
DBLOG:
0_name:
myDbLog:
TIME 1551464601.34015
VALUE hwcmode
0_value:
myDbLog:
TIME 1551515372.93913
VALUE 18
1_name:
myDbLog:
TIME 1551464601.34015
VALUE temp0
1_value:
myDbLog:
TIME 1551464601.34015
VALUE 60
2_name:
myDbLog:
TIME 1551464601.34015
VALUE temp1
2_value:
myDbLog:
TIME 1551464601.34015
VALUE 70.0
3_name:
myDbLog:
TIME 1551464601.34015
VALUE temp0
3_value:
myDbLog:
TIME 1551464601.34015
VALUE 70
4_name:
myDbLog:
TIME 1551464601.34015
VALUE temp1
4_value:
myDbLog:
TIME 1551464601.34015
VALUE 54.0
5_name:
myDbLog:
TIME 1551464596.25372
VALUE pumpstate
5_value:
myDbLog:
TIME 1551464596.25372
VALUE on
Status01_0_name:
myDbLog:
TIME 1551515772.81137
VALUE temp1
Status01_0_value:
myDbLog:
TIME 1551515772.81137
VALUE 36.0
Status01_1_name:
myDbLog:
TIME 1551515772.81137
VALUE temp1
Status01_1_value:
myDbLog:
TIME 1551515772.81137
VALUE 36.0
Status01_2_name:
myDbLog:
TIME 1551515772.81137
VALUE temp2
Status01_2_value:
myDbLog:
TIME 1551515772.81137
VALUE 5.125
Status01_3_name:
myDbLog:
TIME 1551515772.81137
VALUE temp1
Status01_3_value:
myDbLog:
TIME 1551515772.81137
VALUE 36.0
Status01_4_name:
myDbLog:
TIME 1551515772.81137
VALUE temp1
Status01_4_value:
myDbLog:
TIME 1551515772.81137
VALUE 39.0
Status01_5_name:
myDbLog:
TIME 1551515772.81137
VALUE pumpstate
Status01_5_value:
myDbLog:
TIME 1551515772.81137
VALUE off
Status02_0_name:
myDbLog:
TIME 1551515747.75541
VALUE hwcmode
Status02_0_value:
myDbLog:
TIME 1551515747.75541
VALUE auto
Status02_1_name:
myDbLog:
TIME 1551515747.75541
VALUE temp0
Status02_1_value:
myDbLog:
TIME 1551515747.75541
VALUE 60
Status02_2_name:
myDbLog:
TIME 1551515747.75541
VALUE temp1
Status02_2_value:
myDbLog:
TIME 1551515747.75541
VALUE 70.0
Status02_3_name:
myDbLog:
TIME 1551515747.75541
VALUE temp0
Status02_3_value:
myDbLog:
TIME 1551515747.75541
VALUE 70
Status02_4_name:
myDbLog:
TIME 1551515747.75541
VALUE temp1
Status02_4_value:
myDbLog:
TIME 1551515747.75541
VALUE 54.0
bdate_value:
myDbLog:
TIME 1551515757.68888
VALUE -.-.-
btime_value:
myDbLog:
TIME 1551515757.68888
VALUE 20:12:24
dcfstate_value:
myDbLog:
TIME 1551515757.68888
VALUE nosignal
disablehc_value:
myDbLog:
TIME 1551515777.6922
VALUE 0
disablehwcload_value:
myDbLog:
TIME 1551515777.6922
VALUE 1
disablehwctapping_value:
myDbLog:
TIME 1551515777.6922
VALUE 0
flowtempdesired_value:
myDbLog:
TIME 1551515777.6922
VALUE 42.5
get:
myDbLog:
TIME 1551515687.96452
VALUE
hcmode_value:
myDbLog:
TIME 1551515777.6922
VALUE auto
hoursum2_value:
myDbLog:
TIME 1551515372.8757
VALUE 6088
percent0_value:
myDbLog:
TIME 1551515367.41397
VALUE 53
power_value:
myDbLog:
TIME 1551515372.83192
VALUE 18
press_value:
myDbLog:
TIME 1551515757.74431
VALUE 1.869
releaseBackup_value:
myDbLog:
TIME 1551515777.6922
VALUE 0
releaseCooling_value:
myDbLog:
TIME 1551515777.6922
VALUE 0
remoteControlHcPump_value:
myDbLog:
TIME 1551515777.6922
VALUE 0
sensor_value:
myDbLog:
TIME 1551515757.95559
VALUE ok
state:
myDbLog:
TIME 1551515372.93913
VALUE 0_name:
temp0_value:
myDbLog:
TIME 1551515373.00076
VALUE 29
temp2_value:
myDbLog:
TIME 1551515757.68888
VALUE 5.125
temp_value:
myDbLog:
TIME 1551515757.95559
VALUE 36.50
tempmirror_value:
myDbLog:
TIME 1551515757.95559
VALUE 64951
OLDREADINGS:
READINGS:
2019-03-02 09:29:32 0_name
2019-03-02 09:29:32 0_value 18
2019-03-02 09:36:12 Status01_0_name temp1
2019-03-02 09:36:12 Status01_0_value 36.0
2019-03-02 09:36:12 Status01_1_name temp1
2019-03-02 09:36:12 Status01_1_value 36.0
2019-03-02 09:36:12 Status01_2_name temp2
2019-03-02 09:36:12 Status01_2_value 5.125
2019-03-02 09:36:12 Status01_3_name temp1
2019-03-02 09:36:12 Status01_3_value 36.0
2019-03-02 09:36:12 Status01_4_name temp1
2019-03-02 09:36:12 Status01_4_value 39.0
2019-03-02 09:36:12 Status01_5_name pumpstate
2019-03-02 09:36:12 Status01_5_value off
2019-03-02 09:35:47 Status02_0_name hwcmode
2019-03-02 09:35:47 Status02_0_value auto
2019-03-02 09:35:47 Status02_1_name temp0
2019-03-02 09:35:47 Status02_1_value 60
2019-03-02 09:35:47 Status02_2_name temp1
2019-03-02 09:35:47 Status02_2_value 70.0
2019-03-02 09:35:47 Status02_3_name temp0
2019-03-02 09:35:47 Status02_3_value 70
2019-03-02 09:35:47 Status02_4_name temp1
2019-03-02 09:35:47 Status02_4_value 54.0
2019-03-01 19:29:31 associatedWith MQTT2_ebusd_bai
2019-03-02 09:35:57 bdate_value -.-.-
2019-03-02 09:35:57 btime_value 20:12:24
2019-03-02 09:35:57 dcfstate_value nosignal
2019-03-02 09:36:17 disablehc_value 0
2019-03-02 09:36:17 disablehwcload_value 1
2019-03-02 09:36:17 disablehwctapping_value 0
2019-03-02 09:36:17 flowtempdesired_value 42.5
2019-03-02 09:34:47 get
2019-03-02 09:36:17 hcmode_value auto
2019-03-02 09:29:32 hoursum2_value 6088
2019-03-02 09:29:27 percent0_value 53
2019-03-02 09:29:32 power_value 18
2019-03-02 09:35:57 press_value 1.869
2019-03-02 09:36:17 releaseBackup_value 0
2019-03-02 09:36:17 releaseCooling_value 0
2019-03-02 09:36:17 remoteControlHcPump_value 0
2019-03-02 09:35:57 sensor_value ok
2019-03-02 09:29:32 temp0_value 29
2019-03-02 09:35:57 temp2_value 5.125
2019-03-02 09:35:57 temp_value 36.50
2019-03-02 09:35:57 tempmirror_value 64951
Attributes:
IODev ebusMQTT
autocreate 1
bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
devStateStyle style="text-align:right"
icon icoTempHeizung
model E_01_eBus_Status
readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/bai/SetMode:.* { json2nameValue($EVENT) }
ebusd/bai/DateTime:.* { json2nameValue($EVENT) }
ebusd/bai/WaterPressure/get:.* get
ebusd/bai/FlowTemp/get:.* get
ebusd/bai/ReturnTemp/get:.* get
ebusd/bai/OutdoorstempSensor/get:.* get
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }
ebusd/bai/FlowTemp:.* { json2nameValue($EVENT) }
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT) }
ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT) }
ebusd/bai/WPPWMPower:.* { json2nameValue($EVENT) }
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT) }
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT) }
ebusd/bai/FanHours:.* { json2nameValue($EVENT) }
ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }
ebusd/bai/HcHours:.* { json2nameValue($EVENT) }
ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }
ebusd/bai/PartloadHcKW:.* { json2nameValue($EVENT) }
ebusd/bai/DeactivationsIFC:.* { json2nameValue($EVENT) }
ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT) }
ebusd/bai/HwcSetPotmeter:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setStateList on off
stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>Warmwasser: %.1f <br>Aussentemp.: %.1f <br>Pumpe: %s <br>HWC-maxTemp: %.1f <br>HWC-Regler_Max: %.1f <br>HWC-CurrentTemp: %.1f <br>HWC-Mode: %s", ReadingsVal($name,"Status01_0_value",0), ReadingsVal($name,"Status01_1_value",0), ReadingsVal($name,"Status01_3_value",0), ReadingsVal($name,"Status01_2_value",0), ReadingsVal($name,"Status01_5_value",0), ReadingsVal($name,"Status02_1_value",0), ReadingsVal($name,"Status02_2_value",0), ReadingsVal($name,"Status02_4_value",0), ReadingsVal($name,"Status02_0_value",0))}
Testsystem: CID ebusd_3.2_20376
Internals:
CID ebusd_3.2_20376
DEF ebusd_3.2_20376
DEVICETOPIC MQTT2_ebusd_3.2_20376
IODev MQTT2Server
LASTInputDev MQTT2Server
MQTT2Server_MSGCNT 7118
MQTT2Server_TIME 2019-03-02 08:35:14
MSGCNT 7118
NAME MQTT2_ebusd_3.2_20376
NR 51
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-03-02 08:34:53 0_name temp1
2019-03-02 08:34:53 0_value 38.0
2019-03-02 08:34:53 1_name temp1
2019-03-02 08:34:53 1_value 37.0
2019-03-02 08:34:53 2_name temp2
2019-03-02 08:34:53 2_value 5.125
2019-03-02 08:34:53 3_name temp1
2019-03-02 08:34:53 3_value 36.0
2019-03-02 08:34:53 4_name temp1
2019-03-02 08:34:53 4_value 39.0
2019-03-02 08:34:53 5_name pumpstate
2019-03-02 08:34:53 5_value off
2019-03-02 08:34:53 bdate_value -.-.-
2019-03-02 08:34:53 btime_value 20:11:23
2019-03-02 08:30:53 curve_value 1.00
2019-03-02 08:35:13 date_value 02.03.2019
2019-03-02 08:34:53 dcfstate_value nosignal
2019-03-02 03:30:19 disablehc_value 0
2019-03-02 03:30:19 disablehwcload_value 1
2019-03-02 03:30:19 disablehwctapping_value 0
2019-03-02 03:30:19 flowtempdesired_value 42.5
2019-03-02 03:30:19 hcmode_value auto
2019-03-02 08:29:29 hoursum2_value 5207
2019-03-02 05:59:29 percent0_value 53
2019-03-02 08:34:48 press_value 1.869
2019-03-02 03:30:19 releaseBackup_value 0
2019-03-02 03:30:19 releaseCooling_value 0
2019-03-02 03:30:19 remoteControlHcPump_value 0
2019-03-01 18:31:02 running true
2019-03-02 08:34:48 sensor_value ok
2019-03-01 18:31:02 signal true
2019-03-02 08:30:54 temp1_value 55.0
2019-03-02 08:34:53 temp2_value 5.125
2019-03-02 08:34:48 temp_value 37.81
2019-03-02 08:34:48 tempmirror_value 64930
2019-03-02 08:35:13 time_value 08:53:41
2019-03-02 08:35:14 uptime 59875
2019-03-01 18:31:02 version "ebusd 3.2.v3.2-30-gb2c63ac"
Attributes:
IODev MQTT2Server
readingList ebusd_3.2_20376:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/global/uptime:.* uptime
ebusd_3.2_20376:ebusd/bai/Status01:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/DateTime:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FlowTemp:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/430/Hc1HeatCurve:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/HcHours:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/global/running:.* running
ebusd_3.2_20376:ebusd/global/signal:.* signal
ebusd_3.2_20376:ebusd/global/version:.* version
ebusd_3.2_20376:ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/430/HwcTempDesired:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FanSpeed:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/SetMode:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FanHours:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/WPPWMPower:.* { json2nameValue($EVENT) }
ebusd_3.2_20376:ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
Ich habe auch beim Testsystem (denn da läuft MQTT2_Server) das direkte Publishen getestet, funktioniert.
Befehl:
set MQTT2Server publish ebusd/430/Hc1HeatCurve/get
Log:
2019.03.02 08:41:56 4: MQTT2Server_10.0.0.8_38002 ebusd_3.2_20376 PUBLISH ebusd/430/Hc1HeatCurve:{ "curve": {"value": 1.00}}
2019.03.02 08:41:56 5: MQTT2Server: dispatch autocreate:ebusd_3.2_20376:ebusd/430/Hc1HeatCurve:{ "curve": {"value": 1.00}}
2019.03.02 08:41:56 4: MQTT2_DEVICE_Parse: MQTT2_ebusd_3.2_20376 ebusd/430/Hc1HeatCurve => { json2nameValue($EVENT) }
2019.03.02 08:41:56 5: Starting notify loop for MQTT2_ebusd_3.2_20376, 1 event(s), first is curve_value: 1.00
2019.03.02 08:41:56 5: End notify loop for MQTT2_ebusd_3.2_20376
Hier habe ich auch eine zeitgesteuerte Abfrage (alle 5min) eingebaut, weil ja sonst der eBus von sich aus nur Broadcasts (Statusmeldungen) liefert.
+*00:05:00 {
fhem("set MQTT2Server publish ebusd/430/Hc1HeatCurve/get");
fhem("set MQTT2Server publish ebusd/bai/WaterPressure/get");
fhem("set MQTT2Server publish ebusd/bai/FlowTemp/get");
fhem("set MQTT2Server publish ebusd/bai/ReturnTemp/get");
fhem("set MQTT2Server publish ebusd/bai/OutdoorstempSensor/get");
fhem("set MQTT2Server publish ebusd/430/HwcTempDesired/get");
}
eine beliebige Test Zusammenstellung von 2 verschiedenen Topics ( bai/430 )
LG
Reinhart
Zitat von: Reinhart am 02 März 2019, 09:48:20
wenn du mit ClientID die CID meinst, ja die sind unterschiedlich.
(Wieder erst mal zu wenig Zeit)
Das waren die lists von den MQTT2_DEVICEs. Mir ging es um das clientID-Attribut am IO-Device (TYPE=MQTT2_CLIENT).
Ich würde es auch gerne mit dieser IO-Art an's Laufen bekommen, auch wenn es richtig sein müßte, dass es mit MQTT2_SERVER sehr viel einfacher geht. Der Unterschied zwischen beiden IO's ist "nur" der, dass SERVER die Herkunft der Daten kennt, CLIENT nicht. Deswegen benötigen wir ja dieses eine MQTT2_DEVICE, das für CLIENT als IO aus dem Topic-Tree die Herkunft ableitet... Das ist die Funktion dieses ersten templates. Gestalten wir das richtig, verringert sich der Unterschied zwischen den IO-Optionen deutlich. Dazu müssen wir "nur" die bridgeRegexp erweitern, wie in der cref zu MQTT2_DEVICE beschrieben:
Zitatmultiple tuples of <regexp> newClientId are separated by newline
Wenn es dir nicht vorher gelingt, würde ich mich mal später am Tag daran machen, das hier umzusetzen:
Zitat von: Beta-User am 02 März 2019, 08:45:47
Wir packen als erstes das general-Client-template an ;) . Das sollte sich so verhalten wie der MQTT2-Server, indem es ebus-Infos und anderes sauber trennt. Also das erste bridgeRegep-Element so ändern, dass es _nicht_ auf ebus-Infos paßt und ein zweites dazu, dass alles an das ebus-Gerät weitergibt.
(und dann würde ich mal eine bridgeRegexp am ebus-Gerät testen, die alles, was nicht zum zentralen Steuergerät gehört auf eigene Geräte weiterverteilt).
Zum publish: Die Frage war so gemeint, ob es TomLee jetzt gelungen ist, den passenden publish-Befehl zu finden, indem er das erst mal direkt über das IO macht. Paßt das und die Therme reagiert auch, können wir untersuchen, ob der Sendebefehl im MQTT2_DEVICE richtig zusammengestellt wird. Vorher macht das keinen Sinn.
Jetzt will ich erst noch ein paar Kleinigkeiten im Garten erledigen...
beim eBusd haben wir die Möglichkeit direkt Kommandos in der Konsole absetzen zu können, daher empfiehlt sich für TomLee zuerst ein "ebusctl" mit seinen gewünschten Aktionen, wenn das klappt dann sollte die Syntax für MQTT kein Problem sein.
pi@raspberrypi:~ $ ebusctl f -f HwcTempDesired
r,430,HwcTempDesired,gewünschte Temperatur Warmwasserkreis,,15,b509,0d4400,temp1,s,D1C,,°C,setpoint of domestic hot water circuit
r,bai,HwcTempDesired,d.06 Brauchwassersollwert,,08,b509,0dea03,temp,s,D2C,,°C,Gewünschte Warmwasser Solltemperatur
pi@raspberrypi:~ $ ebusctl r -f HwcTempDesired
55.0
pi@raspberrypi:~ $ ebusctl r -f -c 430 HwcTempDesired
55.0
pi@raspberrypi:~ $ ebusctl f HwcTempDesired
430 HwcTempDesired = 55.0
bai HwcTempDesired = no data stored
wie man sieht, gibt es das Register "HwcTempDesired" zweimal, einmal in der Therme und einmal im Steuergerät (Calormatic). Es sind zwar unterschiedliche Register, aber derselbe Wert. Das Steuergerät greift ja auch auf das Register in der Therme (bai) zu und speichert den Wert nochmals bei sich.
Der Typ ist beide male gleich:
TYPE MQTT2_CLIENT
LG
So,
mal ein kurzer Zwischenstand (dient auch dazu, dass ich das ggf. auch ins Wiki bekomme...):
1. Bei MQTT2_CLIENT als IO-Device sollte man
-- sicherstellen, dass die ClientID dieses Devices gegenüber dem MQTT-Server (mosquitto) nicht irgendwo doppelt belegt ist; am einfachsten dort das entsprechende Attribut setzen (wichtig, wenn man mehrere FHEM-Installationen betreibt und auf mehreren ein MQTT2_CLIENT vorhanden ist mit demselben Namen!)
-- das erste Gerät, das reinkommt, wird als Genera-Bridge genutzt. Die bridgeRegex sollte sein:
attr MQTT2_testsystemMQTT2CLIENT bridgeRegexp tele[/]([^/]+)[/]?.*:.* "$1"\
cmnd[/]([^/]+)[/]?.*:.* "$1"\
shellies[/]([^/]+)[/]?.*:.* "$1"\
(ebus[^/])[/]([^/]+)[/].*:.* "$1"
Damit bekommt man dann auch z.B. Tasmotas und (hoffentlich) shellys besser in den Griff, der MQTT2_CLIENT verhält sich dann ähnlich wie ein MQTT2_SERVER beim autocreate (hoffe ich zumindest). Dazu mache ich demnächst noch einen separaten Post im MQTT-Bereich auf, das ist ein allgemeines Thema, vermutlich kommt das dann mit dem nächsten update der templates.
2. Ebus-Basis
Dann sollte mit den nächsten eingehenden Nachrichten von ebus-Seite dann ein weiteres Gerät angelegt werden, typischerweise mit der CID "ebus".
Das sollte dann auch eine bridgeRegexp bekommen - anschließend repräsentiert es (so jedenfalls mein bisheriges Verständnis) den ESP:
attr MQTT2_ebusd bridgeRegexp [^/]+[/](bai)[/].* "ebusd_bai"\
[^/]+[/](broadcast)[/].* "ebusd_bai"\
[^/]+[/]([\d]+)[/].* "ebusd_$1"
3. Weitere Geräte
Nach dem nächsten Satz Infos vom ebus werden dann mind. zwei weitere Geräte angelegt, eines für das "bai"-Dingens, eines für jedes Zusatzgerät, das sich hinter einer Nummer verbirgt.
Bei dem "bai"-Gerät sollte dann noch die readingList mit der Langversion von json2nameValue genutzt werden, z.B.:
attr MQTT2_ebusd_bai readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
Soviel mal vorab.
Fragen, bevor es ggf. weitergeht:
- Wäre die Gerätestruktur, die damit grundlegend angelegt werden würde aus eurer Sicht ok? Also: kann man damit was anfangen, oder bin ich gedanklich auf dem Holzweg?
- Dann wäre nicht schlecht, wenn jemand die Schritte 2 bis Ende mal mit dem MQTT2_SERVER nachvollziehen könnte. Müßte eigentlich gleich sein, kann aber auch sein, dass da irgendwas noch angepaßt werden muss, weil mehr/weniger über die CID bekannt ist.
Hoffe, das hilft euch weiter, ich muß mich jedenfalls erst mal sehr bei Reinhart bedanken! Das Testsystem hat mir im Verständnis des MQTT2_CLIENTS und der bridgeRegepx-Anwendung sehr weitergeholfen.
(Du könntest den Zugang jetzt erst mal wieder schließen, wir können das ja ggf. wiederholen, wenn weiterer Bedarf bestehen sollte).
Gruß, Beta-User
Hallo,
wie man an meinem gezeigten Beispiel sieht hatte ich nach viel Spielerei und ausprobieren am Ende über den SetMode_hwctempdesired_value Wert den ich aus Setmode geholt hatte versucht die Temperatur zu setzen, da hab ich dann wohl was durcheinander gebracht.
Es klappt wenn man wie Reinhart schon erwähnt hat den Wert aus HwcTempDesired holt und nicht aus Setmode, so hatte ich das scheinbar anfangs auch getestet.
Hier jetzt ein funktionierendes Beispiel das mit 2 verschiedenen Topics funktioniert.
defmod MQTT2_Test_Ebusd MQTT2_DEVICE
attr MQTT2_Test_Ebusd IODev MQTT2_CLIENT
attr MQTT2_Test_Ebusd bridgeRegexp ([A-Za-z0-9]*)/([A-Za-z0-9]*).*:.* "$1_$2"
attr MQTT2_Test_Ebusd devStateStyle style="text-align:right"
attr MQTT2_Test_Ebusd event-on-change-reading .*
attr MQTT2_Test_Ebusd icon icoTempHeizung
attr MQTT2_Test_Ebusd jsonMap Status01_0_value:1_Vorlauf Status01_0_name:0 Status01_1_value:1_Ruecklauf Status01_1_name:0 Status01_2_value:1_OutdoorstempSensor Status01_2_name:0 Status01_3_value:1_Fragez Status01_3_name:0 Status01_4_value:1_HwctempSensor Status01_4_name:0 Status01_5_value:1_Pumpe Status01_5_name:0 WaterPressure_press_value:WaterPressure WaterPressure_sensor_value:0 FlowTempDesired_temp_value:FlowTempDesired CirPump_onoff_value:CirPump Hc1HeatCurve_0_name:0 Hc1HeatCurve_0_value:Hc1HeatCurve z1DayTemp_tempv_value:z1DayTemp HwcTempDesired_tempv_value:HwcTempDesired
attr MQTT2_Test_Ebusd model E_04a_eBus_Test_Status01+WaterPressure+CirPump+HwcTempDesired+Hc1HeatCurve+z1DayTemp
attr MQTT2_Test_Ebusd readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT, 'CirPump_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }
attr MQTT2_Test_Ebusd setList Hc1HeatCurve:2.0,2.05,2.10 ebusd/700/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired:50,51,52,53,54,55,56,57,58,59,60 ebusd/700/HwcTempDesired/set $EVTPART1\
z1DayTemp:20,21,22,23,24 ebusd/700/z1DayTemp/set $EVTPART1
attr MQTT2_Test_Ebusd stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>WW-Temperatur: %.1f <br>Aussentemperatur.: %.1f <br>Pumpe: %s <br>Fragez: %.1f <br>Druck: %.1f <br>Zirk.pumpe: %s", ReadingsVal($name,"1_Vorlauf",0), ReadingsVal($name,"1_Ruecklauf",0), ReadingsVal($name,"1_HwctempSensor",0),ReadingsVal($name,"1_OutdoorstempSensor",0), ReadingsVal($name,"1_Pumpe",0), ReadingsVal($name,"Fragez",0), ReadingsVal($name,"WaterPressure",0), ReadingsVal($name,"CirPump",0))}
attr MQTT2_Test_Ebusd webCmd Hc1HeatCurve:HwcTempDesired:z1DayTemp
attr MQTT2_Test_Ebusd webCmdLabel Heizkurve:Warmwasser:Raumtemperatur
setstate MQTT2_Test_Ebusd Vorlauf: 54.0 <br>Ruecklauf: 0.0 <br>WW-Temperatur: 49.0 <br>Aussentemperatur.: 13.7 <br>Pumpe: 68 <br>Fragez: 0.0 <br>Druck: 2.2 <br>Zirk.pumpe: off
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_Fragez 0.0
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_HwctempSensor 49.0
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_OutdoorstempSensor 13.688
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_Pumpe 68
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:17 1_Vorlauf 54.0
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:02 CirPump off
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 Hc1HeatCurve 2.05
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 HwcTempDesired 55
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 WaterPressure 2.240
setstate MQTT2_Test_Ebusd 2019-03-03 13:17:01 z1DayTemp 22
Zitat- Wäre die Gerätestruktur, die damit grundlegend angelegt werden würde aus eurer Sicht ok?
Deine vorgeschlagene bridgeRegexp hab ich mal in meiner General-Bridge angewendet.
attr MQTT2_testsystemMQTT2CLIENT bridgeRegexp tele[/]([^/]+)[/]?.*:.* "$1"\
cmnd[/]([^/]+)[/]?.*:.* "$1"\
shellies[/]([^/]+)[/]?.*:.* "$1"\
(ebus[^/])[/]([^/]+)[/].*:.* "$1"(Bemerkung am Rande die Leerzeichen sind ja immer noch da :P )
Daraufhin wird folgendes Device wie von dir beschrieben angelegt.
defmod MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev MQTT2_CLIENT
attr MQTT2_ebusd readingList ebusd/global/uptime:.* uptime\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT) }\
ebusd/700/Hc1HeatCurve/get:.* get\
ebusd/700/z1DayTemp/get:.* get\
ebusd/700/HwcTempDesired/get:.* get\
ebusd/bai/WaterPressure/get:.* get\
ebusd/bai/FanSpeed/get:.* get\
ebusd/bai/HwcStarts/get:.* get\
ebusd/bai/HwcHours/get:.* get\
ebusd/bai/HcHours/get:.* get\
ebusd/bai/HcStarts/get:.* get\
ebusd/bai/FanHours/get:.* get\
ebusd/bai/CirPump/get:.* get\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT) }\
ebusd/bai/Status01:.* { json2nameValue($EVENT) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT) }\
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT) }\
ebusd/bai/CirPump:.* { json2nameValue($EVENT) }
attr MQTT2_ebusd room MQTT2_DEVICE
setstate MQTT2_ebusd 2019-03-03 14:53:19 0_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 0_value 41.0
setstate MQTT2_ebusd 2019-03-03 14:53:19 1_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 2_name temp2
setstate MQTT2_ebusd 2019-03-03 14:53:19 2_value 13.688
setstate MQTT2_ebusd 2019-03-03 14:53:19 3_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 3_value 0.0
setstate MQTT2_ebusd 2019-03-03 14:53:19 4_name temp1
setstate MQTT2_ebusd 2019-03-03 14:53:19 4_value 55.0
setstate MQTT2_ebusd 2019-03-03 14:53:19 5_name pumpstate
setstate MQTT2_ebusd 2019-03-03 14:53:19 5_value off
setstate MQTT2_ebusd 2019-03-03 14:52:02 associatedWith MQTT2_General_Bridge
setstate MQTT2_ebusd 2019-03-03 14:53:29 bdate_value 03.03.2019
setstate MQTT2_ebusd 2019-03-03 14:53:29 btime_value 14:53:31
setstate MQTT2_ebusd 2019-03-03 14:52:29 date_value 03.03.2019
setstate MQTT2_ebusd 2019-03-03 14:53:29 dcfstate_value valid
setstate MQTT2_ebusd 2019-03-03 14:52:01 get
setstate MQTT2_ebusd 2019-03-03 14:52:02 hoursum2_value 459
setstate MQTT2_ebusd 2019-03-03 14:52:02 onoff_value off
setstate MQTT2_ebusd 2019-03-03 14:52:01 press_value 2.355
setstate MQTT2_ebusd 2019-03-03 14:52:01 sensor_value ok
setstate MQTT2_ebusd 2019-03-03 14:53:29 temp2_value 13.688
setstate MQTT2_ebusd 2019-03-03 14:52:01 tempv_value 55
setstate MQTT2_ebusd 2019-03-03 14:52:29 time_value 14:52:30
setstate MQTT2_ebusd 2019-03-03 14:53:36 uptime 172426auf dieses wiederum das bridgeRegexp angewendet:
attr MQTT2_ebusd bridgeRegexp [^/]+[/](bai)[/].* "ebusd_bai"\
[^/]+[/](broadcast)[/].* "ebusd_bai"\
[^/]+[/]([\d]+)[/].* "ebusd_$1" Werden diese Geräte automatisch erstellt
MQTT2_ebusd_700
MQTT2_ebusd_broadcast
MQTT2_ebusd_bai
MQTT2_ebusd_global
MQTT2_ebusd_scan (Neustart vom Ebusd vorausgesetzt)
Das passt glaube ich so wie du dir das vorgestellt hast. MQTT2_SERVER hab ich/nutz ich nicht.
Trotzdem hat man das ganze zuvor genauso auch ohne ein zusätzliches Bridge-Device gehabt.
Zitat von: TomLee am 03 März 2019, 15:19:30
Das passt glaube ich so wie du dir das vorgestellt hast. MQTT2_SERVER hab ich/nutz ich nicht.
Trotzdem hat man das ganze zuvor genauso auch ohne ein zusätzliches Bridge-Device gehabt.
Erst mal ganz lieben Dank für's ausprobieren!
Im Moment kann ich noch nicht beurteilen, ob jetzt ein "Einheitsdevice" oder dieses aufgeteilte "besser" ist, du also recht hast, wenn du "trotzdem" schreibst. Für's "vertemplaten" ist vermutlich die gesplittete Variante einfacher, weil ähnliche Geräteklassen dann ganz easy dasselbe template verwenden können sollten, in der Einheitsvariante muß mehr Intelligenz her.
Mal schauen.
Wenn du wieder dein "Einheitsdevice" nutzen willst (was ok ist!), würde ich allerdings vorschlagen, die General Bridge ("MQTT2_testsystemMQTT2CLIENT") weiter so zu lassen. Im ebus-Device wird dann keine bridgeRegexp mehr benötigt.
Bezogen auf dein Einheitsdevice noch das Fragment einer getList:
attr MQTT2_Test_Ebusd getList
Heizkurve:noArg Hc1HeatCurve ebusd/700/Hc1HeatCurve/get\
HwcTempDesired:noArg HwcTempDesired ebusd/700/HwcTempDesired/get\
z1DayTemp:noArg z1DayTemp ebusd/700/z1DayTemp/getKönnte man um die bai-Anfragen erweitern, dann sollte sich ein at zum regelmäßigen Abholen auf
get MQTT2_Test_Ebusd .* reduzieren lassen...
Zitat von: Beta-User am 03 März 2019, 16:45:58
Bezogen auf dein Einheitsdevice noch das Fragment einer getList:
attr MQTT2_Test_Ebusd getList
Heizkurve:noArg Hc1HeatCurve ebusd/700/Hc1HeatCurve/get\
HwcTempDesired:noArg HwcTempDesired ebusd/700/HwcTempDesired/get\
z1DayTemp:noArg z1DayTemp ebusd/700/z1DayTemp/get
Könnte man um die bai-Anfragen erweitern, dann sollte sich ein at zum regelmäßigen Abholen auf
get MQTT2_Test_Ebusd .* reduzieren lassen...
Habs noch nicht umgesetzt aber gefällt mir, Danke.
Zitat von: Beta-User am 03 März 2019, 12:08:17
Fragen, bevor es ggf. weitergeht:
- Wäre die Gerätestruktur, die damit grundlegend angelegt werden würde aus eurer Sicht ok? Also: kann man damit was anfangen, oder bin ich gedanklich auf dem Holzweg?
- Dann wäre nicht schlecht, wenn jemand die Schritte 2 bis Ende mal mit dem MQTT2_SERVER nachvollziehen könnte. Müßte eigentlich gleich sein, kann aber auch sein, dass da irgendwas noch angepaßt werden muss, weil mehr/weniger über die CID bekannt ist.
Gruß, Beta-User
Die Gerätestruktur ist so ok. Das macht Sinn wenn nicht alles im einem Device ist weil es sonst sehr schnell unübersichtlich wird.
Ich habe jetzt den Mosquitto gestoppt und statt dessen den MQTT2_Server gestartet. Funktioniert auch alles soweit, auch der Sonoff kommt brav an. Aber ich werde die Tage jetzt noch weiter testen, bzw. auf einer nackten Installation von vorne beginnen und alle Schritte noch einmal nachvollziehen.
Danke dir für deine Geduld, das Testsystem laß ich heute Nacht noch offen und schließe morgen dann den Zugang, lasse aber alles so laufen wenn es dann später noch was testen gibt.
LG
@TomLee:
Eine Bitte: könntest du in den Thread-Titel noch ein "mqtt2" reinflicken? Hilft ggf., wenn jemand mal danach sucht...
Was das "Einheitsdevice" angeht, vielleicht noch eine Überlegung: Es gibt da ggf. auch Möglichkeiten, die Methoden zu mischen oder später Devices (auch teilweise) wieder zusammenzufügen. Tendenziell würde ich mindestens den ESP und die übrigen Geräte trennen.
Zitat von: Reinhart am 03 März 2019, 17:41:23
Die Gerätestruktur ist so ok. Das macht Sinn wenn nicht alles im einem Device ist weil es sonst sehr schnell unübersichtlich wird.
Danke für die Rückmeldung!
Ist auch eine gute Idee, das Testsystem ggf. erst mal so zu lassen, dass ich später da auch wieder mal rankönnte, siehe nachfolgend :) .
Zum Neustart des ESP (=>scan-Device) bzw. insgesamt zu dem Dingens:
Zum einen wäre hier noch interessant, was darüber an Infos kommt und wie man das ggf. auch ohne Neustart auslösen kann.
So wie ich das in Erinnerung habe, sendet der ESP ja regelmäßig die uptime. Daher wird dieses Gerät auch in jedem Fall automatisch angelegt.
Kann man den Scan automatisch anstoßen und darüber die Infos bekommen, die bislang erst kamen, wenn das "at" aktiv war, könnte man nämlich den Einrichtungsprozess so umgestalten, dass man via template das ESP-Device entsprechend konfiguriert, dass die Abfrage angestupst wird. Entsprechendes würde gelten, wenn man den ESP anders anweisen könnte, mal alle Daten vom Bus zu publishen.
Ich habe den Verdacht, dass das mit den "get"-Pfaden in der readingList nur von dem at kommt (bzw. den "anonymen" publish-Befehlen da drin). Würde man das "intern" lösen, könnte diese Hälfte der readingList entfallen und dann nur noch jeweils in der getList auftauchen, die man ggf. wieder per template generieren kann, wenn wir "das Gerät an sich" haben. (Bitte nachfragen, wenn das zu verkürzt geschrieben ist...)
(Ein list vom scan-Device würde mir da ggf. mal helfen und die Info, was man - neben der Einzelabfrage von Werten via dem .../get-Topic - alles an Befehlen über MQTT hat.
Entsprechendes gilt für Teilbereiche. Wenn es z.B. für die einzelnen Nummernbereiche möglich ist, da eine zentrale Abfrage zu starten, die dann den ganzen Satz liefert, wäre das auch einfacher, als nacheinander Einzelwerte abzurufen.
Zur firmware auf dem ESP noch:
- Es gibt da einen Topic-Tree, der sehr "blöde" ist, weil er einen Punkt enthält. Ich kann leider nicht sagen, wo der herkommt und was da an Info drüber läuft, ich hatte das gestern morgen vollends ausgeblendet... @Reinhart: du findest das auf dem Testsystem im Genera-Bridge-Device. Wenn er nicht benötigt wird oder ein Versehen ist: kann man den ggf. abschalten?
Wenn er benötigt wird: könnte man den umbenennen? Ansonsten brauchen wir jemanden, der besser regexen kann, um die bridge-Regexp anzupassen :( .
- Wo kann ich mich zur Funktionsweise einlesen? Gibt's irgendwo den Quelltext?
(Wie gesagt, ich habe eine Junkers die vermutlich HT3 als Bussystem spricht; evtl. ließe sich die firmware darauf anpassen; dann wäre "nur noch" die Frage, wie an ein vernunftiges Eingangssignal kommen. Daber entweder die Schaltung läßt sich dafür auch verwenden, oder ich brauche halt doch Teile aus dem HT-Proxy)
Zitat von: Beta-User am 01 März 2019, 08:00:37
Als logische Klammer könnten wir das Reading associatedWith nutzen, und in der Darstellung in FHEMWEB das Gruppen-Attribut, ggf. mit einer Sortierpriorität innerhalb der Gruppe.
Da associatedWith bereits von autocreate gesetzt wird vielleicht nochmal als Erinnerungsposten für Skeptiker der gesplitteten Devices ;) . Jedenfalls in FHEMWEB sollte das Setzen einer gemeinsamen Gruppe und die Festlegung einer passenden Sortierung (Attribut sortby am einzelnen Device) bereits ganz ordentliche Darstellungen ermöglichen, auch das devStateIcon kann jeweils individuelle gewählt werden usw. :) .
Zitat
Zur JSONMAP:
Für den Fall, dass doch später alle oder mehrere Devices wieder verbunden werden sollen: Im Moment ist mir noch unklar, ob dann die generelle Verwendung der Langform von json2nameValue sinnvoll wäre. Darüber wäre die Verwendung der Ausgangsquelle (Gerätetyp-Nummer) als Präfix im Großdevice möglich. Das würde zwar zur Orientierung helfen, aber die Variantenvielfalt sehr wahrscheinlich so sehr erhöhen, dass jedenfalls ab da dann der jeweilige User manuell eingreifen muß; eine Logik via template dürfte sich schlicht nicht lohnen...
Wiki-Darstellung:
Im Moment würde ich dazu neigen, die Erkenntnisse bis daher in einem neuen Wiki-Artikel mal zusammenzutragen und in den Praxisbeispielen dann darauf zu verlinken. Ist zwar noch sehr früh, aber vermutlich dauert es insgesamt jetzt nicht mehr so lange, bis wir einen halbwegs konsolidierten Stand haben werden.
Bestimmt fällt mir später wieder das eine oder andere ein, aber für's erste muß das genügen...
ja das mit dem Punkt ist mir auch aufgefallen, ich glaube das kommt aber nur einmal beim booten ansonsten ist der nie zu sehen. Vielleicht kann uns da John weiterhelfen wo der herkommt.
testsystemMQTT2CLIENT:ebusd\.8/global/running:.* running
testsystemMQTT2CLIENT:ebusd\.8/global/version:.* version
testsystemMQTT2CLIENT:ebusd\.8/global/updatecheck:.* updatecheck
version, updatecheck das kommt nur wenn der Dämon gestartet wird und der Scan beginnt.
Aber so wie es jetzt läuft, passt ja alles soweit.
Weil du immer einen ESP erwähnst, das gesamte Testsystem hat keinen, die JSON Strings kommen alle vom eBus Dämon. Die gesamte Doku vom eBus findest du hier auf Johns Github (https://github.com/john30/ebusd/wiki). Es gibt zwar einen Basisadapter mit Erweiterungsplatine auf ESP Basis (Wemos Mini), aber das bekommt Fhem nicht mit weil die Daten immer vom Dämon kommen und nur der mit der Aussenwelt kommuniziert.
Im Augenblick habe ich viel Gartenbetrieb, aber wenn ich Zeit habe dann beschäftige ich mich mit einem schöneren Output der Templates und teste mit Readingsgroups. Das gefällt mit persönlich besser und die gemessenen Temperaturen sind in der Farbe dynamisch. Heiß wird rot, kalt geht ins blau (pahcolor) . Aber auch hier versuche ich kleinere Funktionsgruppen zu erstellen, das ist übersichtlicher. Für jede Gruppe mache ich ein Template.
LG
Vorab mal Danke für die Erläuterungen, irgendwie war ich in der offensichtlich irrigen Annahme, der ESP (genauer: der zweite, da sind ja zwei drauf, wenn ich das richtig im Kopf habe) würde auch die interne Verwaltung der Busdaten machen und man würde gar keinen Dienst auf irgendeinem Rechner benötigen...(Das wäre chick gewesen, und eigentlich müßte ein ESP (vermutlich sogar ein Maple, das wäre meine Lieblingsplattform) sogar in der Lage sein, die ganze Busüberwachung selbständig zu machen. So ist der Vorteil gg. der HT-Proxy Lösung nicht da, soviel jetzt aber abschließend OT).
Im Moment denke ich, es wird das beste sein, den Aufbau - im Prinzip - wie beschrieben zu "vertemplaten", dann finden sich ggf. auch weitere Leute, die das für einzelne typische Baugruppen noch verfeinern können? ReadingsGroups dürften eigentlich für eine "nette" Formatierung mit mehreren devStateIcons nicht erforderlich sein, das müßte mit den neuen Funktionen (NL in stateFormat) oder mit einer Perl-Variante auch so gehen (Extrembeispiel (https://forum.fhem.de/index.php?action=dlattach;topic=97430.0;attach=115584): https://forum.fhem.de/index.php/topic,97430.0.html ;) ).
Ich werde noch etwas rumexperimentieren mit den attrTemplate-Funktionen im Allgemeinen, um das ggf. übersichtlicher zu machen.
Eine RAW-Definition des scan-Devices wäre noch nett, damit ich ggf. die Infos sauber anderen Geräten zu weisen kann (oder @TomLee: das wäre doch eine Herausforderung, die nach der Vorarbeit mit brigdeRegexp evtl. zu meistern wäre? Bei der Gelegenheit auch gleich noch dieses Mistding mit der "\.8" sauber zuweisen... Btw.: ist das bei allen genau dieser String? Dann könnte man das vermutlich auch einfach mit dem template erschlagen... Das ist nur ein Problem für autocreate (und vermutlich auch nur für MQTT2_CLIENT, die Server-Variante kennt ja die richtige CID ;) ): wenn es keine Zurdnung findet, landet es ganz am Ende "irgendwo", in dem Fall eben in der General-Bridge (weil es durch den Weiterleitungsmechanismus die eigene CID voranstellt, wenn ich das richtig interpretiere).
Ich gehe davon aus, dass man in ein Wiki reinschrieben könnte, dass man dann nach Erstellen des ebus-Devices (das den "Dämon" repräsentiert) und Anwenden des template den Dienst neu starten soll, damit alle Geräte dann dadurch automatisch anlegt werden?
Ansonsten habe ich demnächst auch das "Problem", dass der Garten ruft...
Je nachdem was der Ebusd gerade "rausschickt" (ist meine Erklärung/Feststellung) wird ein MQTT2_ebusd_scan Device (für .8 und .15) angelegt oder die zwei scan.8 und .15 Devices, das vom jeweiligen Zeitpunkt wenn autocreate "greift" abhängig.
Zitat von: Beta-User am 04 März 2019, 17:16:21
Ich gehe davon aus, dass man in ein Wiki reinschrieben könnte, dass man dann nach Erstellen des ebus-Devices (das den "Dämon" repräsentiert) und Anwenden des template den Dienst neu starten soll, damit alle Geräte dann dadurch automatisch anlegt werden?
Das ist leider nicht ganz so, außer ein paar Broadcast kommt da nichts von selbst, deshalb mach ja immer ein Timergesteuertes get auf das was ich haben will. Das war auch in der Testumgebung so, das lief ein Timer der die "get" alle 5 Minuten durchführte.
Das man die Readingsgroups ersetzen kann, da muss ich mich noch einlesen, danke für den Link!
Ansonsten finde die Readingsgroups schon nett weil einiges möglich ist.
LG
Hmm, also es ist nicht nur diese "dusselige" .8 im Topic-Tree, sondern es kann mehrere geben, auch noch mit unterschiedlichen präfixen, und wir wissen nicht, was für was ist und warum... :o Nicht schön.
Stehen denn in allen drei Devices dieselben Dinge drin, nur unterschiedlich zusammengestellt? (Gleiche "eingefangene" Topics, hoffentlich irgendwie unterscheidbar? Wenn das nicht "dynamisch" ist, könnte man es hart via Template codieren, aber dann wäre wichtig zu wissen, was wohin gehört...)
Doof ist halt, dass das Sonderzeichen im ersten Teil des Topictrees steckt, da wollten schon meine diversen Versuche mit passenden Bridge-Anweisungen nicht so recht greifen. (Grummel; vielleicht hat da jemand der besser regexen kann eine Idee? Aber auch der würde eine/mehrere RAW-Definition benötigen, bitte schön ;) .
@Reinhart:
Das "get-at" hatte ich gesehen.
Wie geschrieben halte ich das für "verantwortlich", dass die readingList unnötig lang wird. Besser wäre es m.E., die getLists direkt in den Devices zu definieren, (spätestens) dann könnte man das at mind. dahingehend verkürzen, dass das get auf das Device ausgeführt wird, ohne auf die Perl-Ebene auszuweichen.
Ich fand früher die ReadingsGroups auch eine gute Variante, um was darzustellen. Es ist aber mit dieser Perl- bzw. mehrzeiligen Variante oft nicht (mehr) notwendig; seitdem ich das (vor dem Hintergrund der template-Entwicklung für mehrkanalige Tasmotas) weiß, finde ich die direkte Variante einfacher. Man kann das Gerät selbst verwenden, muß das nicht irgendwohin verschieben und hat direkt eine informative Optik. U.A. meine bisherigen Erkenntnisse dazu noch als further reading: https://wiki.fhem.de/wiki/DeviceOverview_anpassen, dort am Ende Multi-icon-Variante und Perl-Variante (da ist es "etwas" einfacher als bei den HM-Geräten :) ).
So,
leider komme ich grade nicht via ssh auf den Pi, daher anbei zwei ungetestete Templates.
Das erste ist dazu da, eine neue Version des General-Bridge-templates zu testen (meine Gedanken dazu sind in dem Thread mit Rudi bzgl. der Erweiterung der autocreate-Optionen für JSONMAP (https://forum.fhem.de/index.php/topic,98206.msg915821.html#msg915821) zu finden).
Es sollte folgendes passieren: Zum einen wird die CID geändert, zum anderen das Device in denselben Raum verschoben werden wie das IO-Device. Schließlich müßte eine recht enge bridgeRegexp dazu führen, dass z.B. Tasmota- oder shelly-Geräte direkt separat angelegt werden.
Alles, was nicht zugeordnet werden kann (z.B. auch der ebus-Dienst), landet wieder in einem "Sammel"-MQTT2-Device (wie bisher).
Bitte dabei UNBEDINGT darauf achten, dass keine weiteren "großzügigen" bridgeRegeps in der Installation vorhanden sind, sonst haben wir wieder seltsame Effekte.
Das zweite kann dann auf das Sammel-Device angewendet werden.
Eregbnis sollte dann sein, dass auch dieses Device mit einer eigenen CID versehen wird (ebusd), umbenannt (Achtung: das geht nur einmal) und dann eine passende bridgeRegexp enthält, die uns die Geräte aufsplittet - dieses Mal hoffentlich nachhaltig sinnvoll...
Im Monent gibt es also danach mind. 3 ebus-Geräte: Den Dienst an sich (CID:ebusd), das ebusd_bai-Gerät, in das ich auch die broadcast-messages umgeleitet habe (sinnvoll?) und je eines für jedes Gerät, das dann mit dem at abgefragt wird und eine Nummer im Topic-Pfad hat (ebusd_NNN).
In diesen Geräten sollte dann hoffentlich alles landen, was irgendwie mit ebus zu tun hat (und nichts anderes sonst).
Danach kann es wieder ein "Sammeldevice" geben, das alles andere aufliest...
An sich dürfte es auch möglich sein, dass ebus-template direkt auf das Sammel-Device (also ganz zu Beginn) loszulassen, wäre evtl. auch einen Test wert...
Zum at noch:
Reinhart, ich hatte das abgeändert. Das funktioniert auch in der Fassung auf dem Pi, ich weiß allerdings nicht mehr, ob die Abfrage vollständig ist.
Die Infos vom bai-Gerät erhält man übrigens auch, wenn man eine Zeile mit "set ebusMQTT publish ebusd/+/+/get" verwendet. Danach geht aber das IO kurz auf disconnect, was schade ist; erwartet hatte ich, dass man darüber auch direkt alle nummerischen Baugruppen direkt abfragen kann, aber das wollte leider nicht...
(aus dem DEF-Editor, sonst muß man immer ein ; mehr machen):
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/OutdoorstempSensor/get;set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get
An sich würde ich annehmen, dass man die get-Pfade ganz aus den readingList-Attributen bekommt, wenn man entsprechende getList's definiert und dann ein get <device> bla absetzt.
Alles was ich getestet habe funkioniert prima!
Auch die direkten Abfragen mit dem at get klappen tadellos. Ob die "Broadcast" sinnvoll in der "bai" untergebracht sind kann man pauschal nicht verneinen. Aber wenn es wem stört, der kann es ja rausnehmen. Ich würde es so lassen, ist ja ein schönes Beispiel wie man die Gruppen umlenken kann.
Rudi sein autocreate mit dem Wert "complex" funktioniert perfekt, die Definition einer "readingList" in den Templates ist somit zumindest beim eBus überflüssig.
Sehr professionelle Arbeit die du da machst!
LG
Danke für die Blumen ::) .
Zur Info: eben habe ich die überarbeitete Fassung für die GeneralBridge ins svn geschoben und das (weiter reduzierte) ebus-Basis-template.
Da mir das mit dem Filtern nicht gelungen ist, wäre mein Vorschlag, dass ihr mir sagt, wenn ich an dem was tun soll (einen Link für weitere templates einfügen, z.B.), und ihr ansonsten jetzt alle Freiheiten habt, entweder ein unified "Großdevice" aufzuhübschen oder was sinnvolles mit den Baugruppen anzufangen und das dann in einem separaten tmplate-File zu verwalten (wie bisher).
Zum ebus-Basistemplate würde mich noch interessieren, ob das ggf. sauber den "richtigen" ebusd-Namen aus der readingList extrahiert (wenn man den z.B. gg. "ebusd" verändert, weil man mehrere hat...)
Gruß und dann ein schönes WE,
Beta-User
Ich habe heute noch herumgetestet und keine Fehler mehr gefunden!
Das einzige wo ich noch keine elegante Lösung gefunden habe, ist eine Verriegelung wenn jemand aus einem falschem Device ein Template aufruft.
zB: man steht im Device MQTT2_ebusd_bai und versucht das Template "E_05_eBus_430_readingsgroup_Set_Hcurve_Hotwater" zu installieren. Es läßt sich zwar installieren, funktioniert aber nicht weil der zusammen gesetzte Devicenamen "MQTT2_ebusd_BASE_DEV" mit BASE_DEV "bai" zurück liefert und so alles mit falschem BASE_DEV angelegt würde. Andererseits kenne ich BASE_DEV nicht, das kann ja irgend was sein und kann somit nicht verriegeln. Das einzige was ginge, man müsste zB: "HwcTempDesired_temp1_value" prüfen ob er im Device BASE_DEV vorhanden ist, das ist aber schon ganz schön komplex für eine reine Prüfung. Schön wäre hier eine Meldung, "Installation in diesem Device nicht möglich". Das ist aber jetzt meckern auf hohem Niveau!
Im Anhang jetzt die neuen Templates die optisch mit readingsgroups verbessert wurden.
@Beta-User
ich versuche das alles nun im Hauptsystem neu zu installieren und kann hier autocreate "complex" nicht auswählen, der Stand von 00_MQTT2_CLIENT.pm ist ident zum Testsystem, dort gehts.
Kannst du mir einen Tipp geben wie ich das aktivieren kann?
LG
Reinhart
PS: sorry wenn man nicht liest, das geht ja nur am Client!
Zitatder Stand von 00_MQTT2_CLIENT.pm ist ident zum Testsystem
Das bezweifle ich, man kann es aber mit "version" pruefen.
Evtl. fehlt ein Neustart.
Zitat von: Reinhart am 08 März 2019, 17:13:45
Ich habe heute noch herumgetestet und keine Fehler mehr gefunden!
Danke für die Rückinfo; ich hoffe, das bezieht sich auf die via svn ausgelieferten Versionen?
(Es würde wahrscheinlich sinnvoll sein, diese beiden (das 00-er und den ebus-splitter) dann aus anderen template-files zu entfernen, sonst droht Verwirrung bei den usern. Das überarbeitete 00-er ist m.E. auch ein gutes Beispiel, wie man eine Ladung Parameter vorab festlegt (s.u.). Da stehen auch noch auskommentierte FHEM-Befehle drin (würde leider nur bei erstmaliger Anwendung auch so funktionieren, daher deaktiviert), evtl. kann das eine Anregung sein, was man sonst noch so tun kann...
@Rudi:
Eigentlich wäre es für die automatische Erkennung der am ebus angeschlossenen Geräte noch sinnvoll, wenn das Basistemplate für den ebus ein "set <IOdevice> publish ebusd/+/+/get" auslösen würde und auch einen setList-Eintrag mit "get_all" bekäme. Allerdings geht MQTT2CLIENT bei sowas ganz kurz auf disconnected? Habe jetzt nicht untersucht, ob das bei anderen Adressaten auch so ist, würde das aber annehmen. Das wäre nicht sooo toll.
(Leider scheint auch der empfangende ebus-Daemon das nicht vollständig korrekt umzusetzen; es kommen nur die bai-Meldungen zurück; @Reinhart: vielleicht testest du das auch mal direkt auf der mosquitto-Ebene nochmal und gibst das bei einer echten "Fehlfunktion" des Daemon an john weiter; vielleicht kann man das verbessern und dann zentral ergänzen, wenn beide Seiten da problemfrei funktionieren?)
Zitat
Das einzige wo ich noch keine elegante Lösung gefunden habe, ist eine Verriegelung wenn jemand aus einem falschem Device ein Template aufruft.
M.E. liegt das außerhalb dessen, was man mit attrTemplate sinnvollerweise erreichen können sollte.
Aber (auch @Rudi): Was ich - jedenfalls mal als ersten Gedanken - an sich nicht schlecht fände, wäre eine Option, die Zahl der jeweils angezeigten templates etwas reduzieren zu können. Ich habe einen kurzen Test gemacht, ob man die Anzeige (via ?) einzelner Templates damit bedingen kann, dass z.B. die CID ein "ebus" enthält. Führte aber dazu, dass das betr. Template dann gar nicht angezeigt wurde, auch nicht, als die Bedingung gepaßt hat. Kann sein, dass ich da was falsch gemacht habe.
Die Idee dahinter wäre, die mit ? bzw. dann auch in der Dropdown-Liste angezeigten Templates jeweils auf die zu beschränken, die grade relevant sind. Am Beispiel von zigbee2mqtt würde ich dann erst mal im "Normalfall" nur die "Bridge" anzeigen, und alle anderen erst, wenn auch das "zigbee_" in der CID auftaucht (analog für shelly, milight...). Das würde es ggf. noch etwas übersichtlicher machen und erlauben, dass man auch "exotische" templates zentral mit ausliefert.
Zitat
Im Anhang jetzt die neuen Templates die optisch mit readingsgroups verbessert wurden.
Sehen nett aus!
Aber m.E. kann man das schon noch deutlich an einigen Stellen optimieren.
- Zum einen durch den Gebrauch einer JSONMAP gleich für eine Benennung der Readings sorgen; ggf. könnte man vorab die language aus global abfragen, um so den "richtigen" Satz in einen Parameter zu bekommen.
- Was den Namen der Geräte angeht, auf die die RG zugreift, könnte das auch dynamischer vom Namen des devices abhängen, von dem aus das aufgerufen wird (DEVICE statt .
- Was "einfache" Geräte angeht (wie das 430-er), ist es m.E. auch nicht das große Problem, die relevanten Dinge gleich in's Device zu packen. Finde ich persönlich charmanter als ein weiteres Gerät (ich meine da einen Versuch von TomLee gesehen zu haben, auch die beiden setter an die richtige Stelle zu bekommen; sowas habe ich bisher aber selbst noch nicht benötigt). Auch die Balkenanzeige sollte mit devStateIcon im Perl-Modus hinzubekommen sein; ggf. macht es da Sinn, code in myUtils auszulagern, grade, wenn es dann farbig werden soll.
- Die templates 9 und 10 würde ich zugunsten von nur 11 rausnehmen, dafür aber das 11-er um eine getList ergänzen (ein Fragment hatte ich hier mal gepostet, meine ich; ggf. melden, wenn ihr da Hilfe braucht, m.E. ist als Beispiel die "beste" getList die von der Zigbee-Bridge L_01, wobei man auch da die beiden Varianten für die networkmap auch in eine Zeile hätte packen können).
Soll in das ebus-Basistemplate noch ein link rein? Wenn ja, wohin? Vorschlagen würde ich diesen Thread hier, dann müßte aber TomLee das jeweils bitte in den ersten Beitrag aktuell einpflegen, oder den allg. ebus-Installationssthread, dann müßtest du das machen.
Oder willst du das zu gegebener Zeit z.B. nach contrib schieben?
(@Rudi: vielleicht hast du da auch eine bessere Idee?)
Ganz allgemein würde ich den Ebus noch in einer Kurzfassung in die Praxisbeispiele aufnehmen, vielleicht mit einem Link zu einem anderen Artikel, wo dann ausführlichere Infos gut aufgehoben wären. Den müßte dann aber jemand anderes erstellen ;) .
Es gibt schon diverse Inbetriebnahme Threads wo ich schon einmal kurz auf das Thema MQTT2 eingegangen bin. Das werde ich demnächst auf letzten Stand bringen. Ebenso plane ich im eBusWiki das Thema MQTT2 mit Installation und Beispielen noch zu erweitern und auf MQTT2 zu verlinken.
Das Thema alles in einen Pott zu werfen finde ich nicht gut weil das mehrere Hundert bis Tausend Datenpunkte sein können!
Hier ein Beispiel meiner Umgebung mit nur 2 Geräten am eBus ,der Therme (bai) und dem Steuergerät (Calormatric 430) , das sind schon 347 Datenpunkte die ich abfragen könnte. Vermutlich sind dann je nach Hardware einige Register nicht belegt.
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 = 28.02.2019
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.00
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 = 56.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 = 19:43:54
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;09:00:00;-.-.-;9.062
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 = 6141
bai FanMaxSpeedOperation = no data stored
bai FanMinSpeedOperation = no data stored
bai FanPWMSum = no data stored
bai FanPWMTest = no data stored
bai FanSpeed = 1796
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 = 43.06;ok
bai FlowTempDesired = 38.00
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 = 5254
bai HcPumpMode = no data stored
bai HcPumpStarts = no data stored
bai HcStarts = 38200
bai HcUnderHundredStarts = no data stored
bai HeatingSwitch = no data stored
bai HoursTillService = no data stored
bai HwcDemand = no data stored
bai HwcHours = 668
bai HwcImpellorSwitch = no data stored
bai HwcPostrunTime = no data stored
bai HwcSetPotmeter = 54.38
bai HwcStarts = 86400
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 = 9.06;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 = 34.62;64981;ok
bai ReturnTempMax = no data stored
bai SecondPumpMode = no data stored
bai SerialNumber = no data stored
bai SetFactoryValues = no data stored
bai SetMode = auto;38.0;-;-;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 = 35.0;35.0;9.062;41.0;38.0;off
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 = 0.00
bai WaterHcFlowMax = no data stored
bai WaterPressure = 2.010;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 = 7.062
broadcast signoflife = no data stored
broadcast vdatetime = 17:02:46;09.03.2019
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.04 = 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.26 = Vaillant;43000;0215;2002
scan.26 id = 21;11;09;0020028515;0907;006374;N5
"no data stored" bedeutet hier nur das dieser Datenpunkt noch nie angefordert wurde und sich nicht im Buffer befindet.
und hier jene Datenpunkte, die ich für meine Zwecke benötige, das ist auch der Grund warum du in meiner Testumgebung nicht mehr siehst.
430 Date = 28.02.2019
430 Hc1HeatCurve = 1.00
430 HwcTempDesired = 56.0
430 Time = 19:43:54
bai CounterStartattempts1 = 29
bai DateTime = nosignal;09:06:14;-.-.-;9.062
bai DeactivationsIFC = 18
bai FanHours = 6142
bai FanSpeed = 0
bai FlowTemp = 32.50;ok
bai FlowTempDesired = 38.00
bai HcHours = 5255
bai HcStarts = 38200
bai HwcHours = 669
bai HwcSetPotmeter = 54.38
bai HwcStarts = 86400
bai OutdoorstempSensor = 9.06;ok
bai PartloadHcKW = 18
bai ReturnTemp = 32.19;65020;ok
bai SetMode = auto;38.0;-;-;0;0;1;0;0;0
bai Status01 = 32.0;32.0;9.062;38.0;37.0;off
bai Status02 = auto;60;70.0;70;54.0
bai WaterPressure = 1.762;ok
bai WPPWMPower = 53
broadcast outsidetemp = 7.062
broadcast vdatetime = 17:08:49;09.03.2019
Mit einem einzigen Befehl wie "get_all" würde man aber empfindlich den internen Verkehr des eBus sehr beeinträchtigen. Wenn jemand 7 Geräte am Bus hängen hat, sind die Zeitfenster für externe Spielereien schon sehr eng und es kommt unweigerlich zu Fehlern am Bus wenn hier pausenlos gepollt wird. Am liebsten sind mir die Statusmeldungen, die kommen alle paar Sekunden und müssen nicht extra angefordert werden. Das ist auch der Grund warum ich die als erstes in den Templates habe.
Der eBus wird ja hauptsächlich zur internen Kommunikation der Geräte untereinander verwendet und die Schnittstelle dient eigentlich nur dem Servicetechniker um einerseits das System besser parametrieren zu können und Fehler besser orten zu können.
Und ja du hast recht, ich werde noch einige Beispiele aus dem Template rausnehmen weil die sich eh überschneiden. Eigentlich ist so ein Template ja ein extrem hoher Komfort, aber etwas Raum für die eigenen Ideen der Anwender sollte man hier offen lassen.
Was man so sieht, hat ja außer TomLee das noch keiner getestet, geschweige denn die Vorteile dieser neuen Technik kennen gelernt. Viele schrecken vor Mosquitto zurück, das ist jetzt mit der Klick Klack Konfiguration (Templates) ja alles Vergangenheit. Wenn dies die ersten Neueinsteiger feststellen wird es vermutlich einen Run auf diese Methode geben. Bisher war es immer noch ECMD, aber auch nur weil das gut mit vielen Beispielen dokumentiert ist. Und GAEBUS hat ja schon einiges an Komfort angeboten.
LG
Nachdem ich im Hauptsystem MQTT2_Client aktiviert habe, habe ich mir die Logs angeschaut und dabei festgestellt wenn noch ein expandJson mit "ebus.*" in Fhem aktiv ist, dann kommt es offensichtlich aus dem Modul zu Fehler.
2019.03.09 21:00:11 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
"0": {"name": "temp1", "value": 27.0},
"1": {"name": "temp1", "value": 27.0},
"2": {"name": "temp2", "value": 7.750},
"3": {"name": "temp1", "value": 29.0},
"4": {"name": "temp1", "value": 31.0},
"5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:11 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:16 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 22.0},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 0},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 1},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
2019.03.09 21:00:16 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:16 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/430/Hc1HeatCurve:{
"curve": {"value": 0.20}}
2019.03.09 21:00:16 2: expandJSON ej3: garbage after JSON object, at character offset 15 (before "}") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:17 3: netatmo_aussen: poll (MODULE)
2019.03.09 21:00:17 3: netatmo_aussen: requestDeviceReadings (Temperature,Humidity)
2019.03.09 21:00:17 5: publish received for tele/sonoff_electrodragon2/SENSOR, {"Time":"2019-03-09T21:00:16","DHT11":{"Temperature":9.0,"Humidity":26.0},"BH1750":{"Illuminance":0},"TempUnit":"C"}
2019.03.09 21:00:17 3: netatmo_aussen: next dynamic update from device (Temperature,Humidity) at 2019-03-09 21:10:18
2019.03.09 21:00:21 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
"0": {"name": "temp1", "value": 27.0},
"1": {"name": "temp1", "value": 27.0},
"2": {"name": "temp2", "value": 7.750},
"3": {"name": "temp1", "value": 29.0},
"4": {"name": "temp1", "value": 31.0},
"5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:21 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:21 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status02:{
"0": {"name": "hwcmode", "value": "auto"},
"1": {"name": "temp0", "value": 60},
"2": {"name": "temp1", "value": 70.0},
"3": {"name": "temp0", "value": 70},
"4": {"name": "temp1", "value": 54.0}}
2019.03.09 21:00:21 2: expandJSON ej3: garbage after JSON object, at character offset 36 (before ",\n "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:26 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 22.0},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 0},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 1},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
2019.03.09 21:00:26 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 22.0},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 0},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 1},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/DateTime:{
"dcfstate": {"value": "nosignal"},
"btime": {"value": "13:03:11"},
"bdate": {"value": "-.-.-"},
"temp2": {"value": 7.750}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 21 (before ",\n "btime": {"v...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
"0": {"name": "temp1", "value": 27.0},
"1": {"name": "temp1", "value": 27.0},
"2": {"name": "temp2", "value": 7.750},
"3": {"name": "temp1", "value": 29.0},
"4": {"name": "temp1", "value": 31.0},
"5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:31 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/430/Hc1HeatCurve:{
"curve": {"value": 0.20}}
2019.03.09 21:00:31 2: expandJSON ej3: garbage after JSON object, at character offset 15 (before "}") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:41 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/SetMode:{
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 22.0},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 0},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 1},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
2019.03.09 21:00:41 2: expandJSON ej3: garbage after JSON object, at character offset 17 (before ",\n "flowtempdes...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:41 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/bai/Status01:{
"0": {"name": "temp1", "value": 27.0},
"1": {"name": "temp1", "value": 27.0},
"2": {"name": "temp2", "value": 7.750},
"3": {"name": "temp1", "value": 29.0},
"4": {"name": "temp1", "value": 31.0},
"5": {"name": "pumpstate", "value": "off"}}
2019.03.09 21:00:41 2: expandJSON ej3: garbage after JSON object, at character offset 32 (before ",\n "1": {"name"...") at ./FHEM/98_expandJSON.pm line 179.
2019.03.09 21:00:41 2: expandJSON ej3: Bad JSON: ebusMQTT ebusd/430/Hc1HeatCurve:{
"curve": {"value": 0.20}}
2019.03.09 21:00:41 2: expandJSON ej3: garbage after JSON object, at character offset 15 (before "}") at ./FHEM/98_expandJSON.pm line 179.
Die Definition von ej3 war dabei so:
(Sonoff.*|ebus.*|robonect.*:.*:.{.*.*{.*.*}})
Ich habe jetzt ebus entfernt und das Log ist wieder ok.
Eigentlich ist es auch sinnlos, beide Varianten gleichzeitig zu betreiben, man darf es nur nicht vergessen zu entfernen.
LG
Zitat von: Reinhart am 09 März 2019, 17:49:13
Es gibt schon diverse Inbetriebnahme Threads wo ich schon einmal kurz auf das Thema MQTT2 eingegangen bin. Das werde ich demnächst auf letzten Stand bringen. Ebenso plane ich im eBusWiki das Thema MQTT2 mit Installation und Beispielen noch zu erweitern und auf MQTT2 zu verlinken.
Klingt gut, bei Gelegenheit werde ich dann nur kurz in den Praxisbeispielen den ebus erwähnen und erst mal auf den Thread hier und deine Einrichtungsanleitung im Forum verlinken. Dann kannst du das dann "umbiegen" oder ergänzen, wenn mehr im Wiki zu finden ist.
ZitatDas Thema alles in einen Pott zu werfen finde ich nicht gut weil das mehrere Hundert bis Tausend Datenpunkte sein können!
Hmm, vielleicht reden wir da aneinander vorbei:
Auf der MQTT-Seite sollte eine +/+/get-Anfrage alles liefern, was der jeweilige Client eben liefern kann/darf. Das geschieht bei bai, da werden dann aber nur die Datenpunkte geliefert, die der Client dazu verfügbar hat. Sollte eigentlich bei 430 genauso sein (in deiner Konfiguration eben mit den 2 Werten, die man einzeln abfragen kann).
Ob er intern dazu pollen muß, ist eine ganz andere Frage. Dass das ggf. nicht sinnvoll ist, ist ebenso klar, wie dass es keinen Sinn macht, durch so eine Methode plötzlich zusätzliche Datenpunkte "aufzumachen". Das betrifft aber die Programmierung/Konfiguration des Clients (also des ebus-Daemon).
ZitatUnd ja du hast recht, ich werde noch einige Beispiele aus dem Template rausnehmen weil die sich eh überschneiden. Eigentlich ist so ein Template ja ein extrem hoher Komfort, aber etwas Raum für die eigenen Ideen der Anwender sollte man hier offen lassen.
Hmm, sehr viele sind einfach froh, wenn sie mit dem Tool click+play hinbekommen. Wir werden sehen, wie die Nutzergemeinde dazu wächst.
Persönlich finde ich den "MQTT2"-Weg extrem komfortabel und würde (auch wegen der asynchronen Kommunikation) keine anderen Methoden mehr nutzen, wenn der jeweilige entfernte Dienst MQTT anbietet (und ggf. entsprechend abzusichern ist).
Geht bestimmt noch mehr Usern so, aber dazu vielleicht eine kleine Anekdote:
Ich habe mal vor Jahren auf Bitten des Autors die MQTT-Einführungsartikel Korrektur gelesen. In der Antwort auf die Bitte stand sinngemäß: "ist schon irgendwie nett mit dem MQTT, aber bitte verschone mich, ich will das nicht in meiner Installation haben, solange es irgendwie anders geht...!"
Erst mit der sidoh-MiLight-Bridge hatte ich einen sinnvollen Anwendungsfall, aber das war auch noch ein Riesenkrampf mit JSON-Blob-Erstellung in Senderichtung und expandJSON?!? Da habe ich nie verstanden, warum das notwendig ist und wie das eigentlich funktioniert... Dann irgendwelche cpan-Dinge, die mal nicht mal mit apt-get (ohne weiteres) installiert bekommt?!? War mir alles suspekt...
Aber jetzt?
Erlebe ich fast täglich die Rückmeldung: Was, so einfach geht das :o ;D ? Super!
Und wer die (an sich doch einfachen) Zusammenhänge mal geschnallt hat, hat einen superflexiblen Baukasten.
Von daher: Jeder wie er mag, aber ihr dürft davon ausgehen, dass mehr neue User den MQTT-Weg gehen werden.
Und ein (noch entsprechend auszubauendes) gutes Beispiel für JSONMAP sollte es obendrein sein. Aber da seid ihr jetzt am Zug :P !
Da bin ich ganz auf deiner Seite, ich bin auch der Meinung das MQTT sich immer mehr zum Protokoll im Smarthome Bereich entwickeln wird. Wenn man beim Ali schaut, so bietet fast jedes Smarthome fähige Gerät MQTT an, Wifi und HTTP ist da schon eher die Ausnahme.
Zum Thema expandJson, das war lange Zeit der einzige komfortable Weg so einen verschachtelten Json String (siehe Status01) in einzelne Readings aufzudröseln und hat dem leidgeplagten gute Dienste verrichtet. Genau diese Umstände haben besonders Neueinsteiger vor dem Thema MQTT abgeschreckt und genau das hat jetzt Rudolf mit der Implementierung der Templates komplett entschärft und noch ein Zuckerl draufgegeben.
Nur leider, viele wissen das noch nicht und das ist jetzt unsere Aufgabe das zu publizieren!
LG
ZitatAllerdings geht MQTT2CLIENT bei sowas ganz kurz auf disconnected?
MQTT2_CLIENT geht auf disconnected, falls einer der folgenden Attribute _nach_ Einlesen der fhem.cfg geaendert wird: clientId, lwt, lwtRetain, subscriptions, SSL, username. Auch wenn per set Passwort gesetzt wird, oder MQTT2_GENERIC_BRIDGE die subscriptions aendert. Und natuerlich bei Kommunikationsproblemen, mit Fehlermeldung.
Falls ich was uebersehen habe, bitte es mit einem verbose 5 Log belegen.
ZitatWas ich - jedenfalls mal als ersten Gedanken - an sich nicht schlecht fände, wäre eine Option, die Zahl der jeweils angezeigten templates etwas reduzieren zu können
Bisher konnte filter nur auf die Gleichheit mit einem Internal pruefen, wir verwenden aktuell auch nur TYPE=XXX. Ich habe filter umgebaut auf devspec Syntax (siehe https://fhem.de/commandref_modular.html#devspec), damit duerfte man auf so ziemlich alles pruefen, auf Kosten der Performance. Ich hoffe das Problem durch Caching zu minimieren, allerdings muss man nach (relevanter) Attributaenderung FHEM neu starten oder {AttrTemplate_Initialize()} ausfuehren.
@Beta-User
habe soeben das Wiki erweitert und um die eBus Praxisbeispiele (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele) erweitert (Punkt 6 eBus)
Da du der Autor der Wiki Seite bist ersuche ich das zu kontrollieren und gegebenenfalls zu korrigieren oder mir sagen.
Ich glaube es passt hier besser rein als im allgemeinen eBus Wiki wo es eigentlich um den eBus selbst geht. Ich kann es ja von dort auf den Praxisbeispiele Artikel verlinken.
LG
Zitat von: rudolfkoenig am 10 März 2019, 12:47:14
Bisher konnte filter nur auf die Gleichheit mit einem Internal pruefen, wir verwenden aktuell auch nur TYPE=XXX. Ich habe filter umgebaut auf devspec Syntax (siehe https://fhem.de/commandref_modular.html#devspec (https://fhem.de/commandref_modular.html#devspec)), damit duerfte man auf so ziemlich alles pruefen, auf Kosten der Performance. Ich hoffe das Problem durch Caching zu minimieren, allerdings muss man nach (relevanter) Attributaenderung FHEM neu starten oder {AttrTemplate_Initialize()} ausfuehren.
Danke!
Ich teste das mal und "verstecke" dann, was jeweils m.E. nicht paßt. Sollte halt im Wiki dann erwähnt werden, nicht, dass jemand was vermisst ;D ...
(Ich gehe aber davon aus, dass es sich um ein reines Anzeigethema handelt und man "mit Gewalt" immer noch "jedes" template anwenden kann? Bitte ggf. nicht ändern, geht nur darum, wie man das den usern erklärt....).
Zitat von: rudolfkoenig am 10 März 2019, 12:47:14
MQTT2_CLIENT geht auf disconnected, falls einer der folgenden Attribute _nach_ Einlesen der fhem.cfg geaendert wird: clientId, lwt, lwtRetain, subscriptions, SSL, username. Auch wenn per set Passwort gesetzt wird, oder MQTT2_GENERIC_BRIDGE die subscriptions aendert. Und natuerlich bei Kommunikationsproblemen, mit Fehlermeldung.
Falls ich was uebersehen habe, bitte es mit einem verbose 5 Log belegen.
Das teste ich bei Gelegenheit ggf. nochmal und liefere auch die logs, aber beobachtet hatte ich das wie geschrieben bei einem simplen publish mit "ebusd/+/+/get" im Event-Monitor.
@Reinhart:
Danke für den Wiki-Teil. Ich bin noch etwas drübergegangen und habe zunächst mal "nur" manches umsortiert und leicht geändert (du hattest noch ein MQTT-Gerät definiert ;) ), für einen nochmaligen kritischen Blick wäre ich aber dankbar, nicht, dass jetzt was wesentliches fehlt.
M.E. müßte man da aber noch in mehrfacher Hinsicht drüber:
- zu einen, was die Verlinkung im Wiki angeht (Bsp: myUtils-Code, readingsGroup);
- zum anderen, was den Gesamtzusammenhang angeht. Dieser Teil ist nach meinem Geschmack im Moment _an dieser Stelle_ "zu ausführlich"; was attrTemplates sind, steht z.B. weiter unten bzw. wird bei den vorhergehenden Beispielen erläutert; ganz vorne im Artikel steht, dass man MQTT2_SERVER nutzen soll bzw. sich alle Beispiele darauf beschränken (was dann hier aber durchbrochen wird) usw..
Da es m.E. schon Sinn macht, die ebus-spezifische Darstellung tatsächlich ausführlich zu machen, habe ich das erst mal so ausführlich gelassen, damit man es ggf. einfacher in einen eigenständigen Artikel (ebusd mit MQTT2) auslagern kann; wenn das hier bleiben soll, würde ich die "allgemeinen" Themen deutlich kürzen.
Spezielle Dinge, die nur für MQTT2_CLIENT gelten, könnten ggf. in eine Infobox oder so verlagert werden, oder es gibt einen Passus im Artikel zu diesem Modul, in der entsprechende Erkenntnisse landen.
Hätte aber gerne vorher Rückmeldungen dazu, vielleicht denke ich da auch zu "betriebsblind"...
beim Thema eBus habe ich schon gelernt möglichst nicht zu technisch aber dafür Schritt für Schritt mit vielen Codebeispielen vorzugehen. Da wir gerade eine Sammelbestellung von 250 Adaptern beendet haben, waren hier eindeutig der Großteil der Besteller Newcomer. Ich schätze es haben sich gut 200 User neu im Forum registriert um die Bestellung durchführen zu können. Viele davon installieren sich jetzt Fhem nur um ihr Heizgerät auslesen zu können und da kommen jetzt die Templates ins Spiel was ihr Vorhaben erleichtert. Einige koppeln dann mit Loxone oder anderem, aber dafür ist ja Fhem auch sehr gut beschaffen.
Das nur als Hintergrund warum der Artikel was die einzelnen Schritte betrifft sehr genau ausgeführt ist, aber andererseits nicht genauer eingeht was eigentlich Unterschied zwischen Server und Client ist. Immerhin geht es um das Thema Praxisbeispiele, deshalb glaube ich das es in diesem Wiki der Praxisbeispiele besser aufgehoben ist als im eBus Wiki, kann man aber mit geringem Aufwand ändern.
Auf jeden Fall war mein Ziel, von oben nach unten lesen ( Bilder anschauen ) und Klick klack und alles läuft obwohl der Anwender selbst noch keine Erfahrung mit Fhem mitbringt. Ich denke da an mich selbst als ich vor einigen Jahren auch so begonnen habe, ich wollte einfach einen Strom und Gaszähler auslesen und bin durch Zufall auf Fhem gestoßen. Erst in der Praxis habe ich das Potential von Fhem entdeckt und so geht es den meisten Neueinsteigern.
Und ja, verlinken muss ich noch nacharbeiten, da hast du völlig recht, da dies ja wertvolle Informationsquellen sind wenn jemand mehr daraus machen möchte. Man kann sich aber auch überlegen den Teil komplett zu aus dem Wiki zu verbannen und in einen der zahlreichen Inbetriebnahmethreads in reduzierter Form zu posten, dann wird zumindest das Wiki nicht so überladen und dort lesen auch die Neueinsteiger fleißig mit.
Sage mir einfach wie du das handhaben willst.
LG
Sorry, da haben wir uns mal wieder mißverstanden :) :
Der Artikel an sich ist gut! Auch die Bebilderung paßt! Und er gehört m.E. auch ins FHEM-Wiki und nicht "verbannt" (wie kommst du drauf, dass das meine Intension sein könnte :o ?)
Deswegen habe ich ihn auch in Schritt 1 nur dort geändert, wo es m.E. her vom Ablaufverständnis, Wording uä. her Bedarf gab. Da hoffe ich, dass diese Änderungen auch in deinen Augen passen und für Anfänger hilfreich sind.
Dass es auch aus ebus-Sicht ein separates Thema ist, sehe ich auch so. Habe eben auch kurz einen Blick in die Wiki-Seite zum ebus geworfen (https://wiki.fhem.de/wiki/EBUS). Spontan würde ich denken, dass die einfachste Vorgehensweise die wäre, das wie folgt zu machen:
- Aus dem Ebus-Artikel die Visualisierung und Steuerung hinsichtlich des ECMD-Teils ausgliedern in einen separaten Artikel. An der ursprünglichen Stelle nur die Überschrift belassen und eine Summary (wie aktuell zu gaebus).
- Dort im EBUS-Artikel die Option mit MQTT(2) ergänzen (wenn es insgesamt einfacher ist als ECMD und denselben Funktionsumfang (demnächst) haben kann: Vor ECMD. Wieder nur die Überschrift und eine summary.
- Den jetzigen ebus-Teil in den dort (ebus-Wiki) verlinkten eigenen Artikel (komplett "as is"; nur die Überschriften-Level wären anzupassen (und ggf. die Lobhudelei vorneweg weglassen, jedenfalls ich lege auf sowas keinen gesteigerten Wert :P )
- An der Stelle in den Praxisbeispielen würde ich dann eine sehr straffe Fassung belassen (quasi eine Kurzanleitung für Leute, die mit templates schon gearbeitet haben bzw. eine Idee davon haben, wie MQTT tickt), die dann auf den Detailartikel verlinkt, der dann der Schritt-für-Schritt-Einführung von Neulingen dient und weiter hinten (oder einem 2. Teil) dann auch die Details für die bereithält, die in die Steuerungsdetails einsteigen wollen und das mit MQTT2 umsetzen.
Ich hoffe, das ist halbwegs verständlich erklärt...
Zitat von: rudolfkoenig am 10 März 2019, 12:47:14
Bisher konnte filter nur auf die Gleichheit mit einem Internal pruefen, wir verwenden aktuell auch nur TYPE=XXX. Ich habe filter umgebaut auf devspec Syntax (siehe https://fhem.de/commandref_modular.html#devspec (https://fhem.de/commandref_modular.html#devspec)), damit duerfte man auf so ziemlich alles pruefen, auf Kosten der Performance. Ich hoffe das Problem durch Caching zu minimieren, allerdings muss man nach (relevanter) Attributaenderung FHEM neu starten oder {AttrTemplate_Initialize()} ausfuehren.
Ich hatte gestern die MQTT2-templates entsprechend ergänzt (eigentlich hatte ich vorher geglaubt, auch erfolglose Versuche mit der CID (=Internal) gemacht zu haben).
Heute gab es jetzt die erste Beschwerde wg. Performance-Einbußen:
https://forum.fhem.de/index.php/topic,98465.0.html
Für mein Anliegen würde vermutlich für die meisten Fälle die Filterung mit CID genügen, da müßte ich wohl nur mit den shellies und tasmotas was anders machen, aber das sind auch sehr verbreitete Geräte.
Zitat von: Beta-User am 11 März 2019, 20:23:50
[...]
Ich hoffe, das ist halbwegs verständlich erklärt...
Scheint so :) .
Hoffentlich finde nicht nur ich das Ergebnis ganz gelungen...
Eigentlich war ich da grade nur im Wiki, weil ich mir die ReadingsGroup-Dinge nochmal ansehen wollte und kurz zeigen, was ich zwischenzeitlich für meine MySensors-Node als devStateIcon ausgedacht habe:
{my $alivecolor = 'lan_rs485@red';$alivecolor='lan_rs485@green' if (ReadingsVal($name, "state", "dead") eq "alive"); my $pumpcom = ReadingsVal($name, "status1", "on") eq "on" ? "off":"on"; my $relaystate = 'sani_pump'; $relaystate = 'sani_pump@red' if ($pumpcom eq "off"); "<div style=\"text-align:right\" >" . FW_makeImage("$alivecolor","lan_rs485") . " <a href=\"/fhem?cmd.dummy=set $name status1 $pumpcom&XHR=1\">". FW_makeImage("$relaystate","off") . "</a> " . FW_makeImage("sani_boiler_temp","sani_boiler_temp") . " " . ReadingsVal($name,"temperature20","0") . "°C<br>" . FW_makeImage("sani_supply_temp","sani_supply_temp") . " " . ReadingsVal($name, "temperature21", "discon") ."°C " . FW_makeImage("sani_water_hot","sani_water_hot") . " " . ReadingsVal($name, "temperature22", "discon") . "°C</div>"}Das zeigt (farbig) an, ob die Node regelmäßig sendet (rot, wenn nicht), ob die Umwälzpumpe für das Warmwasser an ist (rot/normal; sie kann auch darüber geschaltet werden) und mal exemplarisch drei von den erfaßten Temperaturen (am Ausgang des Kessels, Vorlauf Warmwasser und Rücklauf (an der Pumpe, die die Node (nicht das devStateIcon ::) ) auch wieder ausschaltet, wenn der Rücklauf auch warm ist).
Bei Gefallen können wir gerne schauen, ob und wie sich das für eBus-MQTT2-Zwecke erweitern und umbasteln läßt...
Ja, ich habe gestern etwas nach deinen Vorschlägen um- und aufgeräumt muss aber in den nächsten Tagen noch Feintuning machen.
Das mit deinem devStateIcon schaue ich mir beim eBus noch an.
LG
Zitat von: Reinhart am 13 März 2019, 12:47:45
Das mit deinem devStateIcon schaue ich mir beim eBus noch an.
LG
Hallo Reinhart,
wenn du dich bezüglich Beta-Users Beispiel mit devStateIcon beschäftigt kommt man um die Status0x_x_name und- value Readings ja nicht rum.
Genau hier würde sich jetzt mal anbieten, wie Beta-User auch schon mal zur Optimierung angemerkt hat, jsonMAP mal mit in eines deiner Beispiele aufzunehmen.
Bin der Meinung die Status0x_x_name Werte kann man sich sparen, darum hatte ich sie in meinen geposteten Beispielen immer ausgeblendet und für die Status0x_x_value könnte ich mir vorstellen das man hier geläufige, einheitliche Namen in einem Template schon mal festhält/vorgibt, darauf war ich damals mit dieser Frage (https://forum.fhem.de/index.php/topic,79600.msg908019.html#msg908019) aus.
Gruß
Thomas
Zitat von: TomLee am 13 März 2019, 15:26:46
Genau hier würde sich jetzt mal anbieten, [...] jsonMAP mal mit in eines deiner Beispiele aufzunehmen.
Ich wäre euch sehr verbunden, wenn das klappen würde; gerne nehme ich auch ein "bai"-Device (mit 2 Status-Geräten) in die allgemeinen templates auf, dann findet das auch jemand, der eigentlich mit ebus ggf. nicht viel am Hut hat, aber ein ähnliches Problem ;) ; ich würde das dann sogar nicht mal "wegfiltern" wollen, sondern im Hinweistext auf die Beispielfunktion zu JSONMAP hinweisen :) . In devStateIcon würde ich allerdings dann nur den ersten Status aufnehmen, verbunden mit dem Hinweis, dass es ggf. Sinn macht, die Geräte (händisch oder via template) zu trennen, das ist sonst in der optischen Darstellung unnötig aufgebläht und sollte eigentlich ohne größere Anstrengungen dann auch für weitere Devices übertragen werden können.
ZitatBin der Meinung die Status0x_x_name Werte kann man sich sparen, darum hatte ich sie in meinen geposteten Beispielen immer ausgeblendet und für die Status0x_x_value könnte ich mir vorstellen das man hier geläufige, einheitliche Namen in einem Template schon mal festhält/vorgibt, darauf war ich damals mit dieser Frage (https://forum.fhem.de/index.php/topic,79600.msg908019.html#msg908019) aus.
Nochmal der Hinweis: wenn es geläufige Bezeichnungen (z.B. aus Handbüchern) gibt, bietet es sich an, diese zu verwenden...
Was evtl. noch sinnvoll sein könnte, wäre das ebus-Dämon-Device (den splitter) auch mit einer netten Statusanzeige zu versehen; das sollte eigentlich für alle einheitlich sein (uptime usw.) bzw. ggf. auch einer offline-Meldung als "last-will", wenn der Dämon sowas unterstützt.
Da die templates sich jetzt filtern lassen, wäre es eigentlich keine große Sache, auch die ebus-templates via svn zu verteilen; als Filter würde ich die CID nehmen, die mit "ebus" beginnen muß (siehe zigbee-Beispiele). Allerdings wäre es mir recht, wenn die in einer separaten File enthalten wären, für die es einen anderen Verantwortlichen gibt (ich mache gerne eine Zeitlang den 2. Mann, aber eigentlich sind wir, was gewisse Standards angeht - jedenfalls nach meiner Wahrnehmung - auf einem Stand, der einigermaßen paßt).
Ohne damit je groß gearbeitet zu haben, würde ich vom Gefühl her dazu neigen, die myUtils für den ebus in contib zu verwalten; vielleicht kann Rudi oder sonst wer, der da mehr Erfahrung damit hat, einen Rat dazu geben, ob das sinnvoll ist oder eher nicht?
@TomLee:
Wenn der devStateIcon-Code sehr komplex ist oder sich häufig wiederholt, könnte es auch eine Idee sein, das in die myUtils (@contrib) mit reinzunehmen. Als myUtils lief das am Anfang auch mit den zigbee-(und MiLight)-bulbs; auf die Spitze getrieben könnte der devStateIcon-Code sogar feststellen, welcher "Typ" Device es ist und dann das passend zusammenstellen. Auf den Beispielcode für die Homematic-Thermostate (https://github.com/rejoe2/FHEM/blob/master/99_myUtils_Homematic.pm) hatte ich ja schon mal verlinkt, der "tickt" unterschiedlich, je nachdem, ob es ein Heizkörperthermostat oder ein Wandthermostat ist. Könnte mir gut vorstellen, dass das hier auch ähnlich ist (v.a., wenn die Status-Geräte getrennt werden und sich dann nur im Präfix oder gar nicht mehr in den Readings unterscheiden).
Grundgedanke für den Codeablauf:
Bau ein icon und eine Werteangabe nur dazu, wenn überhaupt das entsprechende Reading vorhanden ist, ansonsten lass es weg...
Bitte melden, wenn meine Anmerkungen zu kurzgefaßt sein sollten oder ich irgendwas sonst konstruktiv beitragen kann.
das mit den Statusmeldungen ist so eine fiese Sache, ich möchte das daher jetzt einmal näher erklären warum ich da keine Übersetzung mit JSONMAP machen möchte.
Die Statusmeldungen haben den großen Vorteil alle paar Sekunden über den Bus zu kommen, weil ja auch intern am Bus damit gearbeitet wird. Das erspart dem Anwender die Abfrage mit get". Der Nachteil ist, das hier keine Nachkommastellen (außer der Außentemp) ausgegeben werden.
Hier zur Veranschaulichung eine direkte Busabfrage.
pi@raspberrypi:~ $ ebusctl r -f status01
54.0;46.0;2.250;39.0;43.0;on
pi@raspberrypi:~ $ ebusctl r -f flowtemp
54.44;ok
pi@raspberrypi:~ $ ebusctl r -f returntemp
46.19;64796;ok
Die Zuordnung der einzelnen Werte im Status steht im hcmode.inc File.
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
Der Originaltext aus der Datenbank heißt beim Vorlauf "FlowTemp" und befindet sich im Register d.40 und findet man im entsprechenden CSV File.
Wenn wir nun hergehen und den Wert Status01_0_value mit einem Jsonmapping durch "Flowtemp" ersetzen, besteht einerseits wieder die Gefahr das wir uns den echten "Flowtemp" eventuell überschreiben, bzw. weiß kein Mensch mehr um was für einen Wert es sich handelt. Genau das möchte ich mit solchen Umbenennungen vermeiden, ist auch egal weil durch die Templates wird das ja automatisch geregelt und richtig dargestellt. Da kann dann stehen was jeder User haben will. Der Ersteller der Templates sollte sich Gedanken über die korrekte Zuordnung machen, nicht der Anwender.
Ich hoffe ich habe meine Bedenken euch nun näher gebracht.
Zum Thema devStateIcon sollten wir doch jedem Anwender selber entscheiden lassen, das ist im Prinzip das selbe Thema wie "notify" und "doif". Einfach ein paar Beispiele mit devStateIcon dazu machen und gut ist es, der User soll dann entscheiden mit was er besser zurecht kommt. Es gibt eben viele Wege die nach Rom führen.
Ich benutzte das devStateIcon bis jetzt zur Darstellung von verschieden farbigen Schaltflächen und das wars, deshalb tu ich mir da etwas schwerer um einen schönen dynamischen Output zu erhalten. Habe heute etwas experimentiert was aber bei mir nicht unbedingt von schnellem Erfolg gekrönt ist.
Was mich bei den readingsGroups etwas stört, ist die Tatsache das man meist in der 99_myUtils mit etwas Code nachhelfen muss. Aber das ist eh bei dem devStateIcon auch so.
LG
betreffend dem devStateIcon, ich habe hier ein weiteres Anwendungsbeispiel mit readingsGroup erstellt. Es geht dabei um den internen Pumpenstatus und den Ventilator zur Brenngasmischung.
Mit readingsGroup geht das relativ einfach, mich würde jetzt interessieren wie man sowas mit dem devStatIcon hinbekommt. Braucht man mehr Code oder weniger? Ziel ist es, je nach Leistung oder Drehzahl das Icon und die Farbe zu ändern (auch unbekannte Zwischenstufen), den Wert in Klammer dazuschreiben und die Texte mit Überschrift zu formatieren. Und das Ganze sollte per Template verteilt werden können.
define eBusPumpe readingsGroup <>,<Vaillant>,< ;Leistung>\
MQTT2_ebusd_bai:<%measure_power>,<Heizungspumpe>,WPPWMPower_percent0_value\
MQTT2_ebusd_bai:<%vent_ventilation_level_automatic>,<Ventilatordrehzahl>,FanSpeed_0_value
attr eBusPumpe cellStyle { "r:1"=>'style="font-weight:bold;;;;font-size:16px"'}
attr eBusPumpe nameStyle style="color:yellow"
attr eBusPumpe room eBus
attr eBusPumpe valueIcon { if($READING eq "WPPWMPower_percent0_value" && $VALUE >= 0 && $VALUE <= 60){ 'sani_pump@lightgreen' }\
elsif($READING eq "WPPWMPower_percent0_value" && $VALUE >= 61 && $VALUE <= 449){ 'sani_pump@green' }\
elsif($READING eq "WPPWMPower_percent0_value" && $VALUE >= 500 && $VALUE <= 4449){ 'sani_pump@orange' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 0 && $VALUE <= 10){ 'vent_ventilation_level_0@grey' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 11 && $VALUE <= 500){ 'vent_ventilation_level_0@lightgreen' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 501 && $VALUE <= 1699){ 'vent_ventilation_level_1@green' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 1700 && $VALUE <= 3000){ 'vent_ventilation_level_2@orange' }\
elsif( $READING eq "FanSpeed_0_value" && $VALUE >= 3001){ 'vent_ventilation_level_3@red' } \
else{ 'file_unknown@grey' }}
attr eBusPumpe valueSuffix {"WPPWMPower_percent0_value"=>" ; ; ; ;(".ReadingsVal($DEVICE,$READING,0)." Watt)",\
"FanSpeed_0_value"=>" ; ; ; ;(".ReadingsVal($DEVICE,$READING,0)." Upm)" }
Bei der Pumpe habe ich es jetzt zum Test für die Bilder auf die Schnelle nicht geschafft, dass sie die Leistung in der Heizung spontan ändert, funktioniert aber. Beim Ventilator war es einfach, da habe ich nur die Heizkurve verstellt und schon bläst er mehr. Bei der Pumpe, muss sich auch die Vorlauftemperatur mit ändern, daher kommt die verzögert erst hoch.
LG
Hallo,
spricht was dagegen jsonMAP dann halt nur für das ausblenden der "unnötigen" Status01_0_name zu sehen und den Status01_0_value Readings "einheitliche" Namen zu verpassen meinetwegen weiterhin mit einem Status0x_ davor, Bsp:
Status01_FlowTemp
Zitat von: Reinhart am 14 März 2019, 09:55:48
Mit readingsGroup geht das relativ einfach, mich würde jetzt interessieren wie man sowas mit dem devStatIcon hinbekommt. Braucht man mehr Code oder weniger? Ziel ist es, je nach Leistung oder Drehzahl das Icon und die Farbe zu ändern (auch unbekannte Zwischenstufen), den Wert in Klammer dazuschreiben und die Texte mit Überschrift zu formatieren. Und das Ganze sollte per Template verteilt werden können.
Das ist noch ungetestet, könnte aber funktionieren, was die Icons, die Zusammensetzung des Textes und die farbigen Icons angeht:
{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $iconPower = $vP < 61 ? 'sani_pump@lightgreen' : $vP <448 ? 'sani_pump@green' : $vP <4448 ? 'sani_pump@orange' : 'file_unknown@grey'; my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $iconFSpeed = $vFS < 11 ? ''vent_ventilation_level_0@grey'' : $vFS < 499 ? ''vent_ventilation_level_0@lightgreen'' : $vFS <1699 ? ''vent_ventilation_level_1@green'' : $vFS <3001 ? ''vent_ventilation_level_2@orange'' : 'vent_ventilation_level_3@red'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$vP",'file_unknown@grey') . " (. $vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$vFS",'vent_ventilation_level_3@red') . " ( $vFS Upm)</div>"}(Alles in eine Zeile und als devStateIcon).
Um die Textfarbe usw. hinzubekommen, das entweder bei dem ersten div mit dazuschreiben und ggf. Anführungszeichen escapen, oder evtl. gibt es auch eine Formatierungsoption bei den Device-Attributen. Geht jedenfalls ziemlich sicher auch.
Die Code-Länge mag ich nicht beurteilen, da kann man etwas tricksen, wie ihr seht... Aber so steht es halt direkt im Gerät bei Anwendung eines templates für dieses Gerät. Und man _muß_ den code auch nicht in eine myUtils auslagern. Aber es wäre recht einfach, das umzusetzen.
(Grundsätzliche Anmerkung: eigentlich finde ich es nicht optimal, durch ein template weitere/andere Geräte zu definieren, die ggf. schon vorhanden sind, deswegen mag ich das mit den devStateIcons mehr wie die RG-Lösung).
(edit, hatte den Zwischenpost nicht gesehen, war aber schon soweit):
Was die Unterscheidung zwischen Broadcast und dem "eigentlichen" Status angeht: hier wäre vielleicht eine JSONMAP hilfreich, die das zwar auseinanderhält, aber den Readingnamen aus dem Status_x verkürzt, z.B. zu "S1_Flowtemp" für das Flowtemp-Reading aus Status 1.
Bei dieser Art des erweiterten Auspackens stört mich halt schon immer, dass die Readingnamen so (meist unnötig) lang werden, das ist aber eigentlich nur was optisches... Das war aber mit der Grund, warum ich gegen "complex" als default war.
Danke für dein Beispiel, ich habe mich jetzt etwas damit beschäftigt aber ganz bekomme ich das nicht zu laufen, es werden keine Icons angezeigt. Habe aber die Syntax etwas abgeändert weils sonst nicht läuft.
Ich habe den $name durch den Devicenamen ersetzt und bei den Icons die Doppelquotas entfernt, sonst meckert der Syntaxcheck von Fhem. Was mir generell auffällt, das devStateIcon öffnet in Fhem kein Editorfenster, man muss alles in der kleinen schmalen Zeile editieren und wird bei einer so langen Zeile schnell unübersichtlich. Auch habe ich versucht die Zeile zu verstehen, aber da muss man schon tief in der Materie sein.
{ my $vP = ReadingsVal("MQTT2_ebusd_bai", "WPPWMPower_percent0_value", "4448"); my $iconPower = $vP < 61 ? 'sani_pump@lightgreen' : $vP <448 ? 'sani_pump@green' : $vP <4448 ? 'sani_pump@orange' : 'file_unknown@grey'; my $vFS = ReadingsVal("MQTT2_ebusd_bai", "FanSpeed_0_value", "3001"); my $iconFSpeed = $vFS < 11 ? 'vent_ventilation_level_0@grey' : $vFS < 499 ? 'vent_ventilation_level_0@lightgreen' : $vFS <1699 ? 'vent_ventilation_level_1@green' : $vFS <3001 ? 'vent_ventilation_level_2@orange' : 'vent_ventilation_level_3@red'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$vP",'file_unknown@grey') . " (. $vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$vFS",'vent_ventilation_level_3@red') . " ( $vFS Upm)</div>"}
Man muss aber eins bedenken, mit devStateIcon kann man nur in einen Device bearbeiten, will man aus "MQTT2_ebusd_bai" aber weitere Readings zur Anzeige bringen ist das so nicht komfortabel möglich, bzw. erscheinen dann halt alle untereinander. Bei einer readingsGroup wird einfach ein neuer Name vergeben und man kann beliebig viele unterschiedlich formatierte Readings mit Balken, Icons oder Text anzeigen. Aber Optik ist immer Geschmacksache und liegt im Auge des Betrachters, der eine mag's so, der andere wieder ganz anders, sonst würden wir ja alle dieselbe Frau haben wollen.
Aber interessant ist diese Methode auf jeden Fall, nur zweifle ich daran das hier ein Neueinsteiger was ändern oder dazu bauen kann. Solange das alles aus dem Template kommt ist es ok, dass muss ja auch keiner zwingend verstehen.
Zum Thema Template und "complex", ich finde das sehr gut, weil wirklich schön differenziert wird auch wenn die Namen jetzt länger werden ist das kein wirkliches Malheur. Ja, mit dem Vorschlag von TomLee "Status01_FlowTemp" kann man auch gut leben weil man aus dem Namen weiß wo das Reading herkommt. Dann müsste man allerdings auch diesen Translate im Template berücksichtigen und den Rest unangetastet lassen, denn so gut wie es jetzt funktioniert geht es kaum besser.
Ich habe jetzt im Testbetrieb am Hauptsystem Mosquitto und MQTT2_Client und am Testsystem MQTT2_Server laufen beide auf einem separaten eBusadapter.
LG
Danke für's testen!
$name funktioniert, das nutze ich selbst auch an einigen Stellen und in den mqtt2.templates ist es auch häufiger drin; das mit den Doppelquotas ist seltsam, da hatte ich irgendeinen Bock geschossen, sorry. (Der code war ausdrücklich untested, vermutlich hätte es gereicht, die dusseligen Doppelquotas zu entfernen...).
ZitatDann müsste man allerdings auch diesen Translate im Template berücksichtigen und den Rest unangetastet lassen, denn so gut wie es jetzt funktioniert geht es kaum besser.
Wie bereits geschrieben, wäre ich sehr froh, ein oder zwei Beispiele für die JSONMAP-Funktionalität in den templates zu haben ;) .
Dass man dann sinnvollerweise einen Standard incl. JSONMAP ausliefert, der dann "nur" erst mal das "Standarddevice" mit einer "Status01_FlowTemp"-Benennung (o.ä.) berücksichtigt, ist soweit klar. Ziel dieser Übung wäre "nur", bestimmte Geräte, die immer/häufig anzutreffen sind, direkt funktional anzuzeigen und ggf. grundlegend bedienbar zu haben (wie das 430-er mit der Vorlauftemperatur/Heizkurve).
Dazu sollte dann aber nur der Standard abgedeckt werden (ich würde sogar Farbe vermeiden), und der user muß dann auch nicht mit dem Code an sich beschäftigen oder in dem kleinen Fensterlein rumwerkeln (das kann man auch irgendwo auf textFieldLong umstellen; ich kopiere das im Moment immer in einen Editor und dann wieder zurück, sobald das steht, muss man da ja auch nicht mehr ran...) Das sollten die "Experten" vorher soweit "ausgekocht" haben, dass der Normaluser eine vernünftige Basis hat (daher legen wir uns ja grade unter Autos, die wir erst kennenlernen müssen).
Wer dann mehr will, kann (und soll!) dann weitere Dinge tun können (gerne mit ReadingsGroup!) oder das eigentliche Device irgendwo verstecken, devStateIcon löschen und stateFormat verwenden...
Wegen dieser "unkomfortablen" Zugriffsmöglichkeiten auf devStateIcon auch nochmal der Hinweis, dass man den eigentlichen Code auch auslagern kann (was sinnvoll wäre, wenn man eh' eine myUtils mit ausliefern sollte). Wer sich dann intensiver damit beschäftigen will, kann den Code dann in myUtils anpassen.
Zusammengefaßt nochmal:
Es ist keine "alles-oder-nichts"-Diskussion, die wir hier haben sollten, m.E. wäre eine Mischform sogar wünschenswert; also der Spur nach so:
- Basisfunktionalität einschl. des Setzens von Zielwerten wie Heizkurve usw, das ganze hübsch verpackt: aus dem jeweiligen template direkt am Gerät, ohne viel Farbe, Dynamik ggf. nur aus dem Icon selbst (Bsp: 3-er Lüfter)
- alles andere: ReadingsGroup, myUtils-Code, Farbverläufe mit pah-Color... (FHEM eben!) ganz nach Belieben, gerne auch mit weiteren Templates zum Ausprobieren
Zitat von: Reinhart am 14 März 2019, 15:56:34
Zum Thema Template und "complex", ich finde das sehr gut, [...]
Auch hier: Alles-oder-nichts liegt mir fern; das hat seine volle Berechtigung, wenn man auf komplexe Geräte schaut (deswegen bettle ich ja wegen der JSONMAP ::) ...).
Es ist nur in dem Moment "von hinten durch die Brust ins Auge", wenn man JSONMAP braucht, um wieder Reading-Namen zu haben, die z.B. sprachsteuerungstauglich sind, "nur", weil man den JSON vorher "complex" ausgepackt hat ;) . Ich persönlich finde es jetzt super, dass wir beide Welten zufrieden stellen können, auch wenn es evtl. (noch) Nebenwirkungen geben könnte, die mir bislang entgangen sind, aber bis daher ging das Baugefühl dazu soweit auf.
[OT]
Zitat von: Reinhart am 13 März 2019, 20:16:03
Die Zuordnung der einzelnen Werte im Status steht im hcmode.inc File.
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
Der Originaltext aus der Datenbank heißt beim Vorlauf "FlowTemp" und befindet sich im Register d.40 und findet man im entsprechenden CSV File.
Das hcmode.inc File hab ich mir jetzt mal angeschaut, dachte wenn du FlowTemp und d.40 erwähnst kann man hier auch Rückschlüsse ziehen woher die anderen Werte kommen. Ist aber nicht so. Bei mir kommt unter Status01_3_value mein 1_Fragez :P immer 0.0 rein.
Welcher Wert im CSV File ist denn
WW Temperatur,
Speichertemperatur ist bei mir die Warmwasserspeichertemperatur wo wird den noch eine Temperatur bezüglich WW gemessen ?
[/OT]
@Beta-User
Ja, machen wir so wie du in deiner Zusammenfassung schreibst.
Übrigens mit dem $name hast du recht, es waren nur die Doppelquotas, gerade nochmals getestet. Aber das wesentliche sind noch die fehlenden Icons, die sollten wir noch hinbekommen. Du kannst auch noch auf den Testraspi drauf wenn du da was testen willst.
Das mit der Auslagerung in die myUtils sollten wir wirklich in Betracht ziehen, denn dann bleibt alles übersichtlicher.
Weil du die Sprachausgabe erwähnt hast, ich habe myTTS laufen und Alexa. Bei Alexa ist es eh egal, den da hat man eh den "alexaname" und bei myTTS benutze ich ebenfalls die myUtils weil ich da noch die Lautstärke je nach Tageszeit einstelle. Aber du hast schon recht, es ist mit so "wilden" Namen schon etwas komplizierter.
Ich steuere sonst die ganze Heizung auch via Alexa und eBus und bekomme auch via Fhem Echomodul alle wichtigen Messwerte direkt vom eBus (aufbereitet) vorgelesen. Das meiste läuft aber hier über einfache Dummies die über notify dann Code in der myUtils ausführen oder dann in der Alexa-App als Routine weiter verarbeitet werden.
Was ich dich noch fragen wollte, kann man eigentlich aus dem Template die Bash aufrufen (kopieren oder mit wget Code aus dem Github holen)?
@TomLee
klären wir das bitte in einem Inbetriebnahmethread, wird sonst zuviel OT hier und ich weiß nicht ob John hier mitliest, der weiß das alles aus dem FF.
Moin zusammen :) .
Sorry für den doppelt fehlerhaften Code gestern, da war außer den doppel-Anführungszeichen auch noch der Fehler drin, dass bei der eigentlichen Icon-Generierung dann statt der Variable für das Icon die für den Wert herangezogen war - konnte so nicht gehen :( ...
Jetzt also:
1. "Einfaches" nichtfarbiges devStateIcon
{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $iconFSpeed = $vFS < 11 ? 'vent_ventilation_level_0' : $vFS < 499 ? 'vent_ventilation_level_0' : $vFS <1699 ? 'vent_ventilation_level_1' : $vFS <3001 ? 'vent_ventilation_level_2' : 'vent_ventilation_level_3'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("sani_pump",'file_unknown') . " ($vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$iconFSpeed",'vent_ventilation_level_3') . " ($vFS Upm)</div>"}
Zur Erläuterung: Der eigentliche Rückgabewert des Perl-Codes ist html-Code. Dieser wird in der letzten "Zeile" gebildet, also beginnend mit "<div style. Dabei werden verschiedene "Text"-Elemente miteinander verbunden (concatenation). Zunächst etwas Formatierung (dafür erforderliche Anführungszeichen sind escaped), dann etwas echter Text, dann Perl-Code, der ein Icon zurückgibt (hier im ersten für die Pumpe fest angegeben), dann wieder Text, wobei die Werte-Variable mit drin ist. Dann wieder ein Icon, dieses Mal aus der vorher gefundenen Variable, Rest wie vor, mit dabei dann das Ende der html-Formatierung...
Was das "Finden" der Variable angeht, ist das eine sehr kurz geschriebene if ... else mit weiteren nachfolgenden if ... else- Abfragen. Sobald der erste "Hit" da ist, gibt es einen Rückgabewert. Da aufsteigend sortiert, kann man einfach mit dem kleinsten Wert beginnen und dann immer größer werden ;) .
2. "Einfaches" dynamisch-farbiges devStateIcon
{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $iconPower = $vP < 61 ? 'sani_pump@lightgreen' : $vP <448 ? 'sani_pump@green' : $vP <4448 ? 'sani_pump@orange' : 'file_unknown@grey'; my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $iconFSpeed = $vFS < 11 ? 'vent_ventilation_level_0@grey' : $vFS < 499 ? 'vent_ventilation_level_0@lightgreen' : $vFS <1699 ? 'vent_ventilation_level_1@green' : $vFS <3001 ? 'vent_ventilation_level_2@orange' : 'vent_ventilation_level_3@red'; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$iconPower",'file_unknown@grey') . " ($vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$iconFSpeed",'vent_ventilation_level_3@red') . " ($vFS Upm)</div>"}
Funktioniert im Prinzip wie das andere, nur dass hier auch das Icon für die Pumpe farbig gemacht wird und der Ventilator nicht nur gestuft ist, sondern auch gefärbt.
3. voll-dynamisch-farbiges devStateIcon
Dann wollte ich das Color-Dingens mal antesten, klappt soweit auch. Aber es ist jetzt trotzdem nur erst mal nur ein ziemlich willkürlicher Versuch, weil mir zum einen nicht klar ist, welche Farbausgaben denn eigentlich für die Hardware sinnvoll ist und zum anderen, wie die genaue Parametrierung der pahColor-Funktion funktioniert. Da könnt ihr ja noch dran drehen, Details finden sich u.a. hier: https://wiki.fhem.de/wiki/Color#Farbskala_mit_Color::pahColor (https://wiki.fhem.de/wiki/Color#Farbskala_mit_Color::pahColor).
{ my $vP = ReadingsVal($name, "WPPWMPower_percent0_value", "4448"); my $colPower = substr(Color::pahColor(0,50,4449,$vP,0),0,6); my $iconPower = 'sani_pump@'.$colPower; my $vFS = ReadingsVal($name, "FanSpeed_0_value", "3001"); my $colFSpeed = substr(Color::pahColor(0,50,4000,$vFS,0),0,6); my $iconFSpeed = 'vent_ventilation_level_'; $iconFSpeed .= $vFS < 499 ? '0@' : $vFS <1699 ? '1@' : $vFS <3001 ? '2@' : '3@'; $iconFSpeed .= $colFSpeed; "<div style=\"text-align:right\" > Heizungspumpe: " . FW_makeImage("$iconPower",'file_unknown@grey') . " ($vP Watt)<br>Ventilatordrehzahl: " . FW_makeImage("$iconFSpeed",'vent_ventilation_level_3@red') . " ($vFS Upm)</div>"}
4. myUtils
Bei Bedarf kann ich auch die myUtils-Geschichte noch angehen, aber da habt ihr eigentlich auch genug eigene Erfahrung, oder? (Meine eigene Installation ist übrigens bei weitem nicht so ausgereift wie deine, @Reinhart ;) ). Dazu vielleicht noch eine Anregung: Auf dem Test-Pi gibt es _eine_ 99_myUtils.pm. Da scheint im Moment alles mögliche drin zu sein, ich habe nicht im Detail nachgesehen, ob das nur ebus-spezifische Dinge waren. Es wird m.E. übersichtlicher, wenn man für ebus-Zwecke eine weitere pm erstellt, also z.B. 99_myUtils_ebus.pm (bitte den initialize-Namen auch entsprechend anpassen); das macht es auch einfacher, das später zentral bereitzustellen.
5. Funktionsaufruf von myUtils via devStateIcon
Ist in der Regel einfach, gebraucht wird halt der Name, also mind. den übergeben (mit $name, das kann dann auch in den myUtils wieder von @ nach $name übergeben werden).
Wenn es für den user sehr einfach sein soll, würde ich an eine Funktion devStateIcon_ebus() denken, und dann ($name, $type [,color, ?...]) als Parameter übergeben. $type könnte dann "bai", "bai_n" (für weitere Status_n-Geräte), "remote" (ggf. mit unterschiedlichen Varianten) sein, "color" gibt an, ob farbig...
(A propos Farbe: das Grund-Icon finde ich mit der farbigen Flamme überdenkenswert, ich versuche in meiner Installation nur noch Icons zu verwenden, die die Hintergrundfarbe annehmen, wenn ich sie nicht absichtlich anders einfärbe; denke, das ist "ruhiger" - aber Geschmackssache, klar...)
6. Zur Darstellung des ebus-Splitters noch ein Vorschlag (RAW-Darstellung):
attr MQTT2_ebusd devStateIcon 2.true:lan_rs485 2.false:lan_rs485@red 1.true:it_net 1.false:it_net@red
attr MQTT2_ebusd stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
Die Symbole sind etwas willkürlich gewählt, geht vorrangig um die Darstellung dieser Variante...
Kurz zu der Frage nach Code-Aufrufen aus den templates:
Vor der technischen Seite her würde ich annehmen, dass das ginge.
ABER:
Ich halte das nicht für wünschenswert!
Es ist nicht ausgeschlossen, dass ich da meine Meinung ändere, aber ich will kurz erläutern, warum; ihr könnt mir gerne Gegenargumente nennen (und bitte: es ist eine Meinungsäußerung :) )...
M.E. sollten templates im Kern _das Gerät konfigurieren, auf das sie angewendet werden_. Das ist das, was der Nutzer erwarten kann und darf. Sie sind aber _kein Installer oder so was ähnliches, ihre Wirkung sollte jeweils auf das Gerät beschränkt bleiben.
Das war der Hintergrund, warum ich schon die Erstellung von ReadingsGroups mit auf MQTT2_DEVICE-Geräten angewendeten templates nicht so toll finde, aber ok, das ist nur eine Darstellungssache, damit kann ich mich gerade so noch abfinden.
Eigentlich hatte ich z.B. aber schon Skrupel, die Hardware, die repräsentiert wird, durch Konfigurationsbefehle zu "ändern" (tasmota-Kleinschreibung), weil das auch unangenehme Nebenwirkungen haben kann, wenn jemand noch "was anderes" nutzt (openHAB etc.). Aber ok: Da ist vorneweg ein Hinweis drin, wer den nicht liest, muß halt reparieren...
Für das General-bridgeRegexp-MQTT2_DEVICE für den CLIENT als IO hatte ich den template-Code im Prinzip schon fertig, um aus dem aktuellen Device eine Kopie zu ziehen, die CID zu ändern und das dann mit der passenden BridgeRegexp zu versehen. Ich hab's gelassen, u.A. weil ich dann ein evtl. vorhandenes Gerät mit demselben Namen hätte löschen müssen. Echtes Risiko: gering, aber das Prinzip ist einfach nicht gut, der user weiß hinterher nicht richtig, was passiert ist (er kommt auf die Seite mit dem Ausgangsgerät zurück...)
Jetzt aber Daten von "irgendwoher" zu holen (das ist nichts persönliches, es geht um's Prinzip, s.o.), finde ich noch wesentlich weitgehender, v.a., wenn sie ausführbaren Code enthalten.
Lösungsvorschlag dazu:
Wenn ihr sowieso den Code in github pflegt, könnte man eine controls.ebusd.txt-Datei erstellen (siehe z.B. für Signalduino (https://github.com/RFD-FHEM/RFFHEM/blob/master/controls_signalduino.txt)) und dem User z.B. auf der Infoseite zum ebusd-Basistemplate (splitter) mitteilen, dass er diese Datei in seinen update-Pfad einfügt. Dann kann der user das tun oder sich eben darum kümmern, dass er die notwendigen Dinge selbst einpflegt.
Wäre m.E. sauberer.
Hoffe, das hilft euch weiter?
Edit: Bilder...
@Beta-User
ich habe gesehen du hast einiges getestet und es funktioniert auch alles soweit. Die jsonMaps wie TomLee sie haben möchte habe ich mir auch angeschaut und funktioniert ebenfalls. Complex und auch den Eintrag in der readingList habe ich gelassen, aber ein zusätzliches "attr jsonMap" bennent dann um.
Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
zusätzliches jsonMap
Ich baue die nächsten Tage die Templates alle um, bzw. füge die Beispiele der devStateIcons dazu. Muss aber alles testen und das dauert eine Weile.
Ach ja, der neue Style f18 am Testssystem ist interessant, aber an die orange Schrift muss man sich gewöhnen.
LG
Zitat von: Reinhart am 16 März 2019, 19:38:19
Ach ja, der neue Style f18 am Testssystem ist interessant, aber an die orange Schrift muss man sich gewöhnen.
Sorry wg. der Farbe... Das sind nur 3-4 Klicks, dann ist das auch wieder geändert ;D . Das ist einfach f18 mit dem "Preset colors: -> dark" (der defailt gefällt mir nicht so).
Für die template-Geschichte ist es vielleicht ganz gut, hin und wieder zwischen den verschiedenen f18-color-Presets zu wechseln, dann entspricht es am ehesten dem, was ein "Neueinsteiger" dann von FHEM sieht.
Was diese vielen Aspekte aus meinem letzten Post hier angeht:
Sorry, dass das so ein Wust an Teilaspekten ist, ich hoffe, dass es ok ist, wenn ich da alles erst mal nur in der Kürze angerissen habe und keine fertigen Lösungen?
Laß dir Zeit bzw. hol dir vielleicht jetzt auch weitere ebus-Nutzer dazu, m.E. sind wir jetzt so weit, dass der "Werkzeugkasten" einigermaßen steht. Ein paar Bilder im Hauptthread wirken da vielleicht Wunder...
Ein paar Dinge noch, die mir grade noch durch den Kopf gehen:
- Für das Einrichten wäre es evtl. ganz gut, wir könnten noch einen ebus-Befehl (für die Konsole) einfügen, der dann erst mal dazu führt, dass sämtliche vorhandenen Gerätschaften via MQTT präsentiert werden, nachdem der Splitter konfiguriert wurde.
- Dann sollten wir ein template haben für die "430"-er, das dann eine möglichst optimierte setList enthält (ist mind. in Teilen vorhanden)
- dto. für den "bai"
- dann kann man das at entsprechend auf die "get"-Befehle umbauen.
Womit ich nicht zufrieden war, waren die verfügbaren Icons; vielleicht wäre es clever, da mal im Icon-thread nachzufragen, dass jemand noch ein paar Icons bauen mag (die "durchsichtigen", damit es zu f18 paßt). Toll wären neben diversen Pumpenzuständen (off, mehr Level) noch die Signalzustände und ein generelles "ebus"-Symbol (vielleicht ähnlich zu rs485-lan)?
Was die templates angeht, wäre es gut, wir könnten erst das splitter-template komplettieren (ggf. die Symbole später tauschen), dabei erst mal alles "farblos"; das müßte eigentlich sogar ohne Perl-Code gehen.
Dann das bai (mit JSONMAP, aber immer noch farblos); braucht vermutlich Perl wg. der Level->Symbol-Umrechnung.
Dann ein "430"-er mit Steuerungsmöglichkeit; wäre vermutlich eine gute Idee, da statt Text Symbole für die Temperatur- und Kennlinien-Benennung zu verwenden (müßte auch mit der newline in stateFormat gehen; hier wäre noch interessant, ob man die set-Einträge in die stateFormat-Angabe integrieren kann).
Soviel erst mal wieder, schönen Sonntag noch.
im Augenblick habe ich bei den Tests massive Probleme mit Fhem. Seit etwa 3 Tagen wird es immer langsamer und das Öffnen eines Readings oder Menüpunkt dauert bis zu 2 Minuten. Ich hatte zuerst die Sqlite3 Datenbank im Verdacht und habe sie gelöscht, dann geht es wieder bis zu dem Augenblick wo ich beginne den MQTT2_Client zu definieren und Daten zu sammeln. Innerhalb 30 Minuten werden durch autocreate etwa 500 Readings angelegt. Am schlimmsten ist der Rasenmäher der gleich über 200 anlegt, schon alleine die vielen Zeitprogramme.
Das Testsystem funktioniert, aber wenn ich meine produktive fhem.cfg einspiele ist auch dort sofort der Fehler da. Meine fhem.cfg hat an die 6400 Zeilen, das war aber auch vorher so und war sehr schnell. Ich werde daher erst wieder richtig testen können, wenn ich den Fehler im Griff habe. ich beginne jetzt auf einem anderen System mit älteren Sicherungen zu testen.
Was ich bis jetzt mit den Mappings testen konnte funktioniert das bei mir nur zufällig, siehe Bild, da wird nur jeder 2. mit jsonMap angelegt (die roten kommen trotz jsonMap noch durch). Das ist mir aber nicht sonderlich wichtig, weil es eigentlich von hinten durchs Knie geschossen ist, zuerst mit Complex schön brav erfassen und dann mit jsonMap auf ein neues Reading umleiten ist nicht gerade sauber gelöst.
LG
so, ich habe den Fehler jetzt gefunden, eine Fhem2Fhem Verbindung hat plötzlich durchgedreht und etwa 15-20 x pro Sekunde gesendet. Habe es mit der Netzwerküberwachung gesehen das hier am Raspi was nicht stimmt. Komische Sachen, die Verbindung ist seit Jahren stabil gelaufen.
Ich mach nun mit den Templates weiter, das geht nun trotz der Datenmassen wieder sehr schnell.
LG
Klingt schräg, das mit dem FHEM2FHEM, schön, dass du den Fehler gefunden hast.
Was das JSON-Mapping angeht, sollte es schon eindeutige Namen ergeben, nur eben kürzer. Da sah' der Screenshot seltsam aus, weil einiges in dasselbe Reading gemappt war. Da du das selbst nicht für so wichtig ansiehst: Es wäre für mich auch völlig ok, wenn diesen Teil TomLee beisteuern würde; es sollte halt sowas wie ein konsolidiertes Ergebnis geben. (Das ist nicht als Kritik gemeint, es ist ok, wenn du lieber mit den "vollen" Readingnamen umgehen willst, wie gesagt: mir geht es um die Darstellung eines Beispiels für das Funktionsprinzip.)
Ansonsten: Keine Eile!
ich habe nun einiges getestet und auch einige devStateIcons gebaut. Das einzige Problem das ich noch nicht lösen konnte, ist das Anlegen neuer Devices (Dummys nur wegen Gruppierung in eigenem Device) im Room "MQTT2_DEVICE", also im eigenen Room wo alle Devices mit den Readings liegen. Das hat den Sinn, dem Anwender es zu erlauben hier mehrere Templates auszuwählen, sodaß es noch eine schöne Übersicht ergibt. Das Problem ist der Name selbst, der ja innerhalb vom Template eine Variable ist. Momentan lege ich das Template "E_06" in einem anderen Room an und muss es dann händisch umlegen. Eventuell hat da Beta-User noch eine Idee wie man das lösen kann. Meine Versuche mit Quotas und Klammern sind fehlgeschlagen, die werden einfach so angelegt und dargestellt. Selbst String Additionen gehen in die Hose.
Das angehängte Bild ist ein Beispiel der unterschiedlichen Möglichkeiten. Auch die readingsGroups habe ich noch um ein paar erweitert. Bei den test habe ich nun keine Fehler mehr gefunden, löschen von vorhandenen Readings habe ich absichtlich nicht eingebaut und es kommt eine Fehlermeldung das es schon vorhanden ist. Dann schaut jeder vorher nach, nicht das wertvolle Arbeit einfach überschrieben wird.
Ja, mit den Icons wäre es schön wenn wir mehr hätten, aber man kommt auch so durch. Ich persönlich finde aber ein schönes buntes und dynamisches Icon (evtl. mit farbiger Schrift) gibt dem Aussehen ein rundes Gesicht und peppt das schön auf. Daher macht auch die Aufteilung in mehrere Dummy Devices eine bessere Übersicht, aber Design ist immer Ansichtssache.
LG
ZitatDas Problem ist der Name selbst, der ja innerhalb vom Template eine Variable ist.
Kannst du das bitte so erklaeren, dass ich das nachstellen kann?
ZitatJa, mit den Icons wäre es schön wenn wir mehr hätten, aber man kommt auch so durch.
*staun*:
% find www/images -type f | wc -l
1297
Moin zusammen,
das mit dem Namen deute ich so: Du willst ein define im template ausführen, und zwar mit dem TPY MQTT2_DEVICE. Das klappt aber nicht, weil der hintere Teil "DEVICE" ersetzt wird durch den Namen, aber ein solches Modul gibt es natürlich nicht...
Ausweg: copy verwenden? (Ich mag das aber aus prizipiellen Erwägungen nicht so, lieber ist mir, der Anwender erstellt die copy und wendet dann darauf ein template an; die prinzipiellen Einwände, die ich gegen das Erstellen von "ganz anderen" Devices habe, hatte ich ja schon erläutert)
Das mit den images: Es geht um spezielle Dinge, wie z.B. die Pumpendrehzahl durch "mehr Pfeile" anzuzeigen, oder ein spezielles "ebus"-Symbol.
Ich schau mir das am WE voraussichtlich noch intensiver an.
Ansonsten habe ich im Wiki in den Praxisbeispielen jetzt nochmal deutlich was hin- und hergeschoben und das im wesenlichen auf MQTT2_SERVER zugeschnitten.
Wäre nett, wenn ihr einen kurzen Blick drauf werfen könntet und ggf. noch das "Ende" dahingehend ergänzen, dass man z.B. einen Konsolenbefehl hätte, mit dem man auch den "430"-er sichtbar machen könnte - irgendwoher muß der geneigte Anwender ja wissen, was da ist... (Oder weiß er das nach der Einrichtung des Dämons sowieso? Dann wäre _kurz_ der Transfer vom Dämon zu MQTT2_DEVICE darzustellen.
ZitatDu willst ein define im template ausführen, und zwar mit dem TPY MQTT2_DEVICE. Das klappt aber nicht, weil der hintere Teil "DEVICE" ersetzt wird durch den Namen, aber ein solches Modul gibt es natürlich nicht...
Ich habe AttrTemplate erweitert: mit \ kann man alle Parameternamen schuetzen. Also MQTT2_\DEVICE wird zu MQTT2_DEVICE, und nicht wie bisher zu MQTT2_\Lampe
Zitat von: rudolfkoenig am 22 März 2019, 10:09:25
Ich habe AttrTemplate erweitert: mit \ kann man alle Parameternamen schuetzen. Also MQTT2_\DEVICE wird zu MQTT2_DEVICE, und nicht wie bisher zu MQTT2_\Lampe
;D :o ;D
Das beseitigt zwar die prinzipiellen Einwände nicht, ist aber evtl. doch praktisch :) . Dann werde ich das wohl im General-bridge-template auch verwenden...
Kannst du mir und Reinhart dann noch verraten, was wir ans Ende des templates schreiben sollten, wenn wir das neu erstellte Device gleich in FHEMWEB angezeigt bekommen wollen? (Sonst bleibt man beim aufrufenden Device, was - aus Anwendersicht - m.E. etwas intransparent ist).
ZitatWäre nett, wenn ihr einen kurzen Blick drauf werfen könntet...
Was mir aufgefallen ist (heisst aber nicht unbedingt, dass es geaendert werden soll):
- Bei MQTT2_SERVER ist autocreate Voreinstellung (im Wiki wird es noch explizit gesetzt)
- commandref laedt mit https://fhem.de/commandref_modular.html#set schneller
Zitatwas wir ans Ende des templates schreiben sollten, wenn wir das neu erstellte Device gleich in FHEMWEB angezeigt bekommen wollen?
Am besten diesen Wunsch verkneifen, und associatedWith setzen.
Ich koennte was kompliziertes basteln in der Art "trigger $hash->{CL} JS:...", aber das waere FHEMWEB spezifisch, und ich will FHEMWEB immer noch nicht als das einzig moegliche Frontend zementieren.
Zitat von: rudolfkoenig am 22 März 2019, 10:34:37
Was mir aufgefallen ist (heisst aber nicht unbedingt, dass es geaendert werden soll):
- Bei MQTT2_SERVER ist autocreate Voreinstellung (im Wiki wird es noch explizit gesetzt)
Das schaue ich mir nochmal an; beim ebus ist es so, dass man es zur Bereinigung der readingList m.E. tatsächlich erst aus- und dann wieder (anders) einschalten sollte. Oder ist beim MQTT2_SERVER complex die Voreinstellung? Dann würde es in der Tat genügen, die readingList der anderen Devices zu säubern...
Zitat- commandref laedt mit https://fhem.de/commandref_modular.html#set (https://fhem.de/commandref_modular.html#set) schneller
Ähm, eigentlich verwende ich (hoffentlich) durchgängig die entsprechende Vorlage (https://wiki.fhem.de/w/index.php?title=Vorlage:Link2CmdRef&action=edit). Das wäre ggf. eine Sache, die man insgesamt ändern sollte. Soll ich dazu einen Post im Wiki machen, oder hast du eine Idee, wie das ginge? Ich bin in diesen Themen so gar nicht drin...
Zitat
Am besten diesen Wunsch verkneifen, und associatedWith setzen.
Ich koennte was kompliziertes basteln in der Art "trigger $hash->{CL} JS:...", aber das waere FHEMWEB spezifisch, und ich will FHEMWEB immer noch nicht als das einzig moegliche Frontend zementieren.
Bitte nix kompliziertes, das lohnt nicht, bin wie geschrieben auch nicht so begeistert von der Vorgehensweise an sich (wobei associatedWith evtl. eine Aspekt ist, warum man das doch mit defmod usw. lösen sollte, muß mal sacken lassen)...
Einwände für den Fall der Fälle gegen "show" NEWDEVICE? (Ich hoffe, der Aufruf geht halt einfach ins Leere, wenn man das nicht aus FHEMWEB aufruft)
Zitat von: rudolfkoenig am 22 März 2019, 09:26:57
Kannst du das bitte so erklaeren, dass ich das nachstellen kann?
wenn ich im Template angebe:
attr MQTT2_ebusd_status room MQTT2_DEVICE dann entseht daraus ein Room mit dem Namen:
MQTT2_MQTT2_DEVICEweil intern die Variable "DEVICE" den Wert "MQTT2_DEVICE" beinhaltet.
LG
Solte ab morgen mit attr MQTT2_ebusd_status room MQTT2_\DEVICE
funktionieren
Generelle Anmerkung:
Wäre es nicht günstiger, "abgeleitete", neu erstellte Devices in denselben Raum zu packen wie das "Stammdevice"? Fände ich logischer. Code-Ansatz dazu aus dem Generic-Bridge-template (wäre aus den DEVICE-Attribut direkt zu entnehmen):
par:IODEVROOM;Room of the IOdevice; {AttrVal(AttrVal("DEVICE","IODev",""),"room","" ) ? AttrVal(AttrVal("DEVICE","IODev",""),"room","" ) : undef }
@Rudi: gibt es eigentlich dazu eine Art Regel oder Abfolge, die man einhalten sollte, denn damit könnte sich ja unter Umständen dasselbe Ergebnis ergeben, wenn dann das Stammdevice in MQTT2_DEVICE war. Aber ich vermute mal, er wird erst template-weit der vorhandene Parameter DEVICE ersetzt, dann der nächste Parameter (in order of appearance) ausgewertet, die Ersetzung durchgeführt usw.?
Kann das grade nicht gut testen...
Ich wuerde room fuer neu erstellte Geraete auf TYPE (MQTT2_DEVICE) setzen, so macht das auch autocreate.
Und bei Vorhandenen room nicht anfassen.
Generell bin ich da bei dir (und habe das neulich auch so entsprechend in MYSENSORS_DEVICE geändert).
ABER: dieser Auszug war aus dem General-Bridge-Template, und da war die Rückmeldung, dass es eine gute Idee sei, dieses "spezielle Device" in denselben room zu packen wie das IO. Was noch fehlte, war dann auch diesen room anzuzeigen; da du zu "show" bisher nichts kritisches gesagt hast, werde ich wohl das nutzen.
HIER geht es darum, abgeleitete Devices für einen speziellen Zweck (Anzeige für diverse Dinge) zu generieren, wenn ich das richtig verstanden habe. Hätte ich jetzt eine Heizung mit ebusd, kämen die betreffenden Geräte typischerweise alle in einen Raum "Heizung". Würde ich jetzt dazu ein neues Device generieren wollen, fände ich es umständlich, die jeweils aus dem Raum "MQTT2_DEVICE" oder "readingsGroup" wieder in den Heizungsraum holen zu müssen...
Das ist aber ein spezielles Thema, das so eigentlich m.E. nur in diesen beiden Konstellationen (bisher) aufgetreten ist.
show habe ich schon verdraengt, ist nicht von mir.
Sollte funktionieren, wenn man es ueber FHEMWEB aufruft.
Sonst kriegt man eine unverstaendliche Fehlermeldung.
show funktioniert leider nicht...
Habe vorhin trotzdem das GenericBridge-template auf einen defmod umgestellt mit der neuen Option, das DEVICE zu escapen. Wenn man jetzt noch irgendwie "in die Nähe des Zieldevices" käme, wäre das super (in den Room, optimal: direkt zum defmod-Device...).
Dazu habe ich im Moment kleine weitere Idee, eine Steighilfe auf dieses Pferd wäre ggf. nett... (geht aber auch so, Erläuterungen, Warnhinweise usw. sind da, nur noch nicht im Wiki; daher ist es im svn).
ZitatDazu habe ich im Moment kleine weitere Idee, eine Steighilfe auf dieses Pferd wäre ggf. nett...
show funktioniert nicht, weil bei set und attr die Webseite nicht neu geladen wird: der Befehl wird "nur" mit XHR an FHEM uebermittelt, und die neuen Attribute werden angezeigt, weil ueber deren Aenderung fhemweb.js (d.h. die "laufende" Seite) benachrichtigt wird.
Folgendes funktioniert beim Setzen des Attributes ueber FHEMWEB (gerade getestet):
Zitat{ fhem "trigger $FW_wname JS:location.href='$FW_ME?room=mqtt'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
Allerdings benoetigt das "if" hinter dem Befehl eine gerade eingecheckte AttrTemplate Aenderung.
Ohne if gibt es Nebeneffekte, wenn man den Befehl nicht ueber FHEMWEB absetzt.
Wie ich sagte: ich wuerde room nicht anfassen, ich weiss schon warum :)
Zitat von: rudolfkoenig am 23 März 2019, 09:13:56
Wie ich sagte: ich wuerde room nicht anfassen, ich weiss schon warum :)
Hmm, irgendwie kommt man halt um die Frage des Raums nicht rum, wenn man neue Geräte erstellt (was eh' die Ausnahme sein sollte!). Und wenn der User eine Funktion wählt, die ausdrücklich dazu da ist, sollte er wissen, was er tut (ok, sehe ich ein, dass da "Theorie" ne "Praxis", aber vom Prinzip her...).
Aber du hast zum einen mehr Erfahrung und zum anderen gibt es auch das Prinzip, dass irgendwie automatisch erstellte MQTT2-Devices in einem bestimmten Raum landen. Daher wird das jetzt bei der GeneralBridge so werden :) . Reinhart kann das ja mit den ebus-Dingen anders machen, das fände ich in diesem Fall stringenter, aber zum Glück muß ich das nicht entscheiden :P .
Danke auf jeden Fall für den Schubser und vor allem den Code zum Anzeigen des "richtigen Raums" (ich werde das dann vermutlich bei der Bridge so machen, dass man gleich auf der Detailseite landet).
Vielleicht noch eine Sache: Manchmal wäre es ganz praktisch, dem User am Ende noch einen Hinweis anzuzeigen, hier also, dass das Device erstellt wurde und man es jetzt in den "Raum der Wahl" verschieben kann. Ich denke dabei v.a. an spezielle Devices, bei denen man eigentlich nicht umhin kommt, nach der template-Anwendung noch was einzustellen - z.B. Laufzeiten bei einem Rollladenaktor, siehe die beiden templates für tasmota, das ich gestern eingecheckt habe.
Ist aber ein Wunsch mit geringer Prio!
Zum escapen des "DEVICE" noch eine Anmerkung:
Innerhalb der par-Anweisungen bzw. des Perl-Codes da scheint das nicht zu klappen.
par:NEWDEVROOM;Room of the calling device; {AttrVal("DEVCID","room","MQTT2_\DEVICE" )}
Führt zum Rückgriff auf einen Raumnamen, der auch aus dem aufrufenden DEVICE-Namen besteht.
@Reinhart:
Wenn du zum neu erstellten Device (hier:DEVCID) kommen willst, geht das als eine Zeile im template so (heute noch: AttrTemplate.pm aus dem svn): { fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=DEVCID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
Rudi: Danke, das ist eine deutliche Verbesserung!
Selbst wenn die Bridge jetzt halt immer - egal, ob es sich schon gibt und ein anderer Raum attributiert war - im Raum MQTT2_DEVICE landet...
ZitatInnerhalb der par-Anweisungen bzw. des Perl-Codes da scheint das nicht zu klappen.
Habs gefixt.
ZitatManchmal wäre es ganz praktisch, dem User am Ende noch einen Hinweis anzuzeigen, hier also, dass das Device erstellt wurde und man es jetzt in den "Raum der Wahl" verschieben kann.
Habe was eingebaut, nennt sich farewell. Es werden keine Ausdruecke ausgewertet, da ich noch nicht wueeste, wozu.
Falls vorhanden, wird per asyncOutput eine Sekunde nach dem letzten Befehl ein Text angezeigt.
Bin nicht ganz sicher, ob es ohne Nebeneffekte ist, es faellt mir aber nach etwas Experimentieren nichts Besseres dazu ein.
farewell:Thank you for your patience<br>Bye!
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.
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.
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).
wollte euch kurz Rückmeldung geben, die letzte Änderung von Rudolf funktioniert nun perfekt. Habe das SVN 19002 von 12:37 genommen.
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
:)
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 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 ;) .
Zitat von: Beta-User am 23 März 2019, 20:55:55
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)?
ZitatWar 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.
@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).
Zitat von: rudolfkoenig am 24 März 2019, 10:51:51
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 (https://forum.fhem.de/index.php/topic,95581.0.html) 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...
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
eBusSet: unknown attribute model. Type 'attr eBusSet ?' for a detailed list.
Desweiteren kommt die Fehlermeldung beim setzen der Werte.
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
defmod eBusSet readingsGroup <>,<Name>,< ;Ist>,< ; ; ; ; ; ;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!
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() }".)
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
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
@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.
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?
--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
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.
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
Zitat von: Beta-User am 24 März 2019, 12:47:40
@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.
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.
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
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?
Zitat von: Beta-User am 24 März 2019, 08:28:24
Was pah-Color angeht: Hast du da noch irgendwas optimiert bezüglich des "Mittelpunkts" (oder was auch immer dieser Parameter genau ist)?
ich habe noch herausgefunden das hier nur Integer Werte klappen, dass heißt ich habe nun die Heizkurven alle mit 10 multipliziert um die Start,Mittel und Endwerte richtig zu setzen, ansonsten kann man sich noch abhelfen das man den den Startwert höher setzt.
pahColor(20,40,60,$vH,0)Beispiel Vorlauf, hier kann ruhig der Startwert mit 20 Grad beginnen dann gibt es eine bessere Spreizung. 20 Grad ist hier dann die kälteste, also blau, und 60 Grad die wärmste mit rot und dazwischen wird ja nach der Bezier-Approximation berechnet und die eigentlichen Falschfarben gesetzt. Pah hat das ja hier einmal kurz (https://forum.fhem.de/index.php/topic,30128.msg269683.html#msg269683)erklärt, vor allem das der Mittelwert nur ein Kontrollpunkt ist und nur die Steifigkeit und Steigung steuert. Legst du den tiefer, hast mehr Farbanteil von den oberen Farben habe ich so verstanden. Ich lasse den logischerweise in der Mitte.
Bei 20,40,60 ergibt das bei einer Temperatur von 30 Grad noch viel Blauanteil also noch kühler. Bei einer Fußbodenheizung sollte das daher anders gesetzt werden, so etwa: 10,15,30.
LG
Danke für die Rückmeldung zu pah-Color, wie gesagt, hatte ich das nach den ersten kurzen Versuchen nicht näher angesehen und wollte nur sicherstellen, dass du nicht versehentlich davon ausgehst, ich hätte da besondere Intelligenz reingesteckt und das dann (unbeabsichtigt) sowas wie ein Standard wird...
bei nur belegten Werten sieht die Abfrage so aus:
pi@raspberrypi:~ $ ebusctl f -d
430 Hc1HeatCurve = 1.20
430 HwcTempDesired = 55.0
bai CounterStartattempts1 = 29
bai DateTime = nosignal;14:13:30;-.-.-;17.188
bai DeactivationsIFC = 18
bai FanHours = 6266
bai FanSpeed = 3352
bai FlowTemp = 29.12;ok
bai FlowTempDesired = 27.00
bai HcHours = 5367
bai HcStarts = 39100
bai HwcHours = 677
bai HwcSetPotmeter = 54.38
bai HwcStarts = 87400
bai OutdoorstempSensor = 17.62;ok
bai PartloadHcKW = 18
bai ReturnTemp = 29.44;65064;ok
bai SetMode = auto;28.5;-;-;0;0;1;0;0;0
bai Status01 = 28.0;29.0;17.188;34.0;33.0;off
bai Status02 = auto;60;70.0;70;54.0
bai WaterPressure = 1.665;ok
bai WPPWMPower = 0
broadcast outsidetemp = 15.188
broadcast vdatetime = 10:48:50;25.03.2019
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
das Gleiche wie vorher, nur zusätzlich "-d".
Wildcard Abfragen vom eBus werden derzeit ohnehin nicht unterstützt. Alle diese Listen hier kommen ja vom Dämon der die gespeichert hat.
LG
Hmm, wenn jetzt also die Infos aus dieser Liste in der regulären topic-Struktur (wie als Antwort von "get") geliefert werden würden, wäre uns doch geholfen, oder?
Damit könnte man dann zumindest alle Geräte (auch den 430-er) automatisch anlegen. Dann würde dort noch die getList fehlen, was aber für diesen Typ via template kein Problem wäre. Diese beiden setter düften ja auch andere Steuergeräte haben, von daher würde ein universelles template mit diesen beiden settern reichen, oder verstehe ich da strukturell was falsch?
Ich habe mir nun das Problem von Patrick näher analysiert und auch bei mir die Fehlfunktion feststellen müssen.
Protokolliert habe ich am Mosquitto Broker, ist aber auch am MQTT2_Server dasselbe.
Abfrage über readingsGroup oder devStateIcon
Client mosqsub/2522-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/Hc1HeatCurve/set', ... (5 bytes))
ebusd/430/Hc1HeatCurve/set 1.20
.... Befehl geht weg, aber keine Antwort vom eBus
gleiches Beispiel über Fhem Eingabezeile:
Client mosqsub/2676-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/Hc1HeatCurve/set', ... (4 bytes))
ebusd/430/Hc1HeatCurve/set 1.20
Client mosqsub/2676-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/Hc1HeatCurve', ... (27 bytes))
ebusd/430/Hc1HeatCurve { "curve": {"value": 1.20}}
... alles OK, sofort kommt die Bestätigung und der neue Wert von "1.20" wird gesetzt.
Hier noch ein Test mit dem Warmwasser über readingsGroup und devStateIcon
Client mosqsub/2891-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/HwcTempDesired/set', ... (4 bytes))
ebusd/430/HwcTempDesired/set 56.0
Client mosqsub/2891-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/HwcTempDesired', ... (27 bytes))
ebusd/430/HwcTempDesired { "temp1": {"value": 56.0}}
Kein Fehler, sofort wird der neue Wert von 56 Grad gesetzt.
Internals:
CID ebusd_430
DEF ebusd_430
DEVICETOPIC MQTT2_ebusd_430
FUUID 5c914b29-f33f-27bd-356b-58344083eaf4b59e
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 1620
NAME MQTT2_ebusd_430
NR 2839
STATE HwcTempDesired_temp1_value
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 1620
ebusMQTT_TIME 2019-03-25 11:28:18
Helper:
DBLOG:
Hc1HeatCurve_curve_value:
myDbLog:
TIME 1553509630.71937
VALUE 1.20
HwcTempDesired_temp1_value:
myDbLog:
TIME 1553509698.73443
VALUE 56.0
set:
myDbLog:
TIME 1553509694.59489
VALUE 56.0
state:
myDbLog:
TIME 1553509694.48141
VALUE HwcTempDesired_temp1_value
READINGS:
2019-03-25 11:27:10 Hc1HeatCurve_curve_value 1.20
2019-03-25 11:28:18 HwcTempDesired_temp1_value 56.0
2019-03-24 09:34:48 associatedWith MQTT2_ebusd
2019-03-25 11:27:09 get
2019-03-25 11:28:14 set 56.0
2019-03-25 11:28:14 state HwcTempDesired_temp1_value
Attributes:
IODev ebusMQTT
devStateIcon {my $vC = ReadingsVal($name, "Hc1HeatCurve_curve_value", "10")*10; my $colCur = substr(Color::pahColor(5,10,15,$vC,0),0,6); my $iconCur = 'time_graph@'.$colCur; my $vH = ReadingsVal($name, "HwcTempDesired_temp1_value", "30"); my $colHot = substr(Color::pahColor(20,40,60,$vH,0),0,6); my $iconHot = 'sani_water_hot@'.$colHot; ; "<div style=\"text-align:right\" > Heizkurve : " . FW_makeImage("$iconCur",'file_unknown@grey') . "<br>Warmwasser : " . FW_makeImage("$iconHot",'sani_water_hot@red') . "</div>"}
getList Hc1HeatCurve:noArg Hc1HeatCurve_curve_value ebusd/430/Hc1HeatCurve/get
HwcTempDesired:noArg HwcTempDesired_temp1_value ebusd/430/HwcTempDesired/get
group eBus_Hcurve
icon message_tendency_steady
model E_04_eBus_430_Pump_Fan_HeatCurve_HwcTemp
readingList ebusd/430/Hc1HeatCurve/get:.* get
ebusd/430/HwcTempDesired/get:.* get
ebusd/430/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }
ebusd/430/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }
ebusd/430/HwcTempDesired/set:.* set
ebusd/430/Hc1HeatCurve/set:.* set
room MQTT2_DEVICE
setList Hc1HeatCurve_curve_value:0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/430/Hc1HeatCurve/set $EVTPART1
HwcTempDesired_temp1_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/430/HwcTempDesired/set $EVTPART1
webCmd Hc1HeatCurve_curve_value:HwcTempDesired_temp1_value
webCmdLabel .
:.
und hier noch List vom Device 430, ich sehe da keinen Unterschied zwischen der Heizkurve zum Warmwasser, die Heizkurve hat eine Fehlfunktion, Warmwasser funktioniert. Aus der Fhem Kommandozeile geht alles, also kann der eBus es nicht sein der den Fehler verursacht. Gibt es hier unsichtbare Steuerzeichen im Befehl worauf Mosquitto nicht antwortet? Seltsam, aber irgendwas muss das auslösen. Hat vor etwa einer Woche noch funktioniert.
Ich bin noch am grübeln woher das kommen kann, bzw. wie ich das lösen kann, dürfte aber auch Patrick sein Fehler sein.
LG
Zitat von: Beta-User am 25 März 2019, 11:25:19
Hmm, wenn jetzt also die Infos aus dieser Liste in der regulären topic-Struktur (wie als Antwort von "get") geliefert werden würden, wäre uns doch geholfen, oder?
Damit könnte man dann zumindest alle Geräte (auch den 430-er) automatisch anlegen. Dann würde dort noch die getList fehlen, was aber für diesen Typ via template kein Problem wäre. Diese beiden setter düften ja auch andere Steuergeräte haben, von daher würde ein universelles template mit diesen beiden settern reichen, oder verstehe ich da strukturell was falsch?
Ich habe John schon ersucht hier mal rein zu schauen!
LG
Zitat von: Reinhart am 25 März 2019, 11:38:40
Ich habe John schon ersucht hier mal rein zu schauen!
Danke! Macht vermutlich Sinn, das direkt zu klären.
Zu dem anderen Problem:
Ich habe keine wirkliche Idee zur Ursache dieses Problems. Für den Fall, das da was unsichtbares drinsteht: Welchen Editor verwendest du? (Ich habe praktisch nur Linux-Systeme und verwende von daher nur entweder kate oder mcedit).
Und jedenfalls am MQTT2_DEVICE kommt m.E. der Befehl nicht aus dem devStateIcon, sondern aus der setList (iVm. webCmd); die sieht aber jedenfalls von hier aus ok aus, aber hier kann ich auch nicht erkennen, ob ein Editor da was reingemogelt hat, was nicht reingehört.
ich bin dem Fehler schon auf der Spur, wenn ich den 2.Befehl aus der setList entferne (Warmwasser) funktioniert es.
setList Hc1HeatCurve_curve_value:0.2,0.7,0.9,1,1.1,1.2,1.3,1.4,1.5,1.6,1.7 ebusd/430/Hc1HeatCurve/set $EVTPART1
das geht.
attr DEVICE setList\
Hc1HeatCurve_curve_value:0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/BASE_DEV/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired_temp1_value:50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/BASE_DEV/HwcTempDesired/set $EVTPART1
im Template habe ich es so, das funktioniert nicht! Eventuell ist es der Zeilentrenner "\", das teste ich noch alles durch um hier sicher zu sein und vor allem das mir das nicht wieder wo passiert.
und Patrick sein Fehler ist wirklich ist im Template, der ist aber schon in den neuen Versionen beseitigt.
Als Editor nehme ich immer PSPad, der ist eigentlich Linux tauglich und kann direkt via FTP schreiben.
LG
Hmmm, sehr seltsam...
Ich kann mir nicht vorstellen, dass es aus dem Zeilentrenner kommt (kannst beide Zeilen ja mal tauschen). (Dann wäre der ebusd das erste Gerät, das damit Schwierigkeiten hat).
Was rausgeht, sieht ja auch sauber aus, und dass da versteckte Zeichen da sein sollten und diese dann auch noch weitertransportiert werden, übersteigt im Moment auch meine Phantasie ??? . Aber wir erleben ja alle immer mal wieder Überraschungen...
habe das Problem nun genau analysiert und alle Fehler beseitigen können.
Die Syntax ist hier etwas pinkelig und muss bei setlist genau eingehalten werden.
attr DEVICE setList Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/BASE_DEV/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/BASE_DEV/HwcTempDesired/set $EVTPART1
Jede setList muss in einer eigenen Zeile sein, es darf keine Einrückung geben und nach dem ersten EVTPART muss sofort der Zeilen Trenner "\" kommen., dann klappt alles wie es soll. Das gleiche gilt für readingGroups.
Ich hatte das irgendwann einmal geändert, zwecks besserer Übersicht im Template.
Somit hat man auch im Mosquitto Log nichts gesehen.
Ich teste das aber noch ein paarmal ( mit alles löschen und neu anlegen ) durch.
LG
Zitat von: Reinhart am 25 März 2019, 15:26:50
Jede setList muss in einer eigenen Zeile sein, es darf keine Einrückung geben und nach dem ersten EVTPART muss sofort der Zeilen Trenner "\" kommen.,
@Rudi: da das mit den verbotenen Einrückungen ggf. die Übersichtlichkeit extrem reduziert (und an anderer Stelle schon nachgefragt wurde, ob ich das nicht lassen könnte mit den Einrückungen :( ): Wäre es viel Aufwand, die Zeilen beim Übernehmen aus dem template "vorzubehandeln" und vor allem einleitende Leerzeichen automatisiert zu löschen?
Hallo zusammen,
wenn auch etwas zu spät :)
Ich konnte den Fehler selber finden.
Es fehlte ein setList für die einzustellenden Werte auf dem MQTT2_ebusd_700 Device
wenn ich das richtig verstehe braucht ihr eine Art Verzeichnis aller verfügbaren Einträge via MQTT, richtig?
Das lässt sich sicher implementieren, ist nur die Frage, wie man das am besten via MQTT kommuniziert. Bspw. bin ich nicht sicher, wie ein Topic mit Teil-Wildcards überhaupt im ebusd ankäme.
Deshalb vielleicht eher ein "/list" mit oder ohne circuit und mit/ohne name?
Moinmoin,
ich hoffe das hier ist die richtige Kategorie.
Hat jemand bereits ein Dummy/Template erstellt um die Wochenprogramme der Heizung einzustellen?
Ich dachte da ein sowas wie hier zu sehen, nur halt für die einzelnen Wochentage.
https://wiki.fhem.de/w/images/thumb/b/b4/RgThermostate.png/750px-RgThermostate.png (https://wiki.fhem.de/w/images/thumb/b/b4/RgThermostate.png/750px-RgThermostate.png)
Die zu definierenden Zeiten kann man hier, entsprechend des Wochentages, setzen.
ebusctl r z1Timer.Monday
05:00;06:00;14:00;22:00;-:-;-:-
Man müsste hierzu ja nur 3x von - bis pro Wochentag definieren.
Leider bin ich selber nicht so fit in FHEM das ich das selber erstellen könnte :(
Zitat von: john30 am 26 März 2019, 07:19:46
wenn ich das richtig verstehe braucht ihr eine Art Verzeichnis aller verfügbaren Einträge via MQTT, richtig?
Ich würde das so beschreiben:
- Einmal sollten alle vorhandenen Busteilnehmer bekannt gemacht werden. Dazu wäre (aus autocreate- und splitter-template-Sicht) die Minimalanforderung, dass auf EINEM zum jeweiligen Gerät gehörenden Infoelement etwas gesendet wird, also für ein "430"-er-Gerät irgendwas in der Topicstruktur unterhalb "ebusd/430/".
Sinnvollerweise sollte man dazu einfach vorhandene Daten in dem Format verwenden, die auch über eine spezifische "get"-Anfrage zurückkämen. Für das Erstellen des Geräts reicht aber ein einziges Element.
- Super wäre es natürlich, wenn man gleich eine vollständige readingList erstellen könnte; dazu wären alle belegten Datenelemente als Rückmeldung klasse, wieder in derselben Form, wie sie bis dato auch durch eine individuelle get-Anfrage zurückgemeldet wurden.
ZitatDas lässt sich sicher implementieren, ist nur die Frage, wie man das am besten via MQTT kommuniziert. Bspw. bin ich nicht sicher, wie ein Topic mit Teil-Wildcards überhaupt im ebusd ankäme.Deshalb vielleicht eher ein "/list" mit oder ohne circuit und mit/ohne name?
Ich habe auf dem Teil der Strecke Broker-externer Client auch keine größere Erfahrung. Vermutlich hast du mit der Annahme recht, dass Wildcard-Anfragen nur an den Broker gehen und der dann ausliefert, was ihm bekannt ist.
Wenn ich das richtig sehe, wäre die Abfrage nach dem vorhandenen Datenbestand eine Anweisung an den Dämon, also irgendwo unter "ebusd/global/" anzusiedeln?Alle bisherigen Anfragen benötigen ein "get"-Subtopic, es wäre also vermutlich auch hier sinnvoll, das zu verwenden, bliebe die Frage, ob eine bestimmte Payload Sinn macht oder nicht bzw. ob man verschiedene Abfragemechanismen braucht.
Bauchgefühl (ich bin kein ebus-Nutzer, ist also mit Vorsicht zu genießen...) sagt: "ebusd/global/get allStored" (oä). könnte dann alle Datenelemente auf "ihrem" Pfad zurückmelden, die bei ebusctl f -d auch kämen? (Also keine Abfrage an den Bus, nur den aktuellen Datenbestand so raushauen, wie er ist).
Ich unterstelle mal, dass jede Art der Filterung Mehraufwand wäre. Das würde m.E. für das Anlegen der Geräte selbst nicht benötigt, ob es aus Praktikabilitätsgründen sinnvoll sein könnte, auch einzelne Geräte separat abzufragen (mit oder ohne Bus-Befehle), kann ich mangels eigener praktischer Erfahrung mit dem ebus nicht sagen, vermute das aber.
Dazu können wir ja aber auch noch gesondert diskutieren. Vom Gefühl her sinnvoll wäre es m.E., wenn man die "tätlich benötigten" Befehle auch via MQTT ggf. gesammelt, aber risikofrei auch an eine bestimmte Baugruppe übermitteln könnte. Bei dem 430-er gibt es z.B. heute ein at, das immer die beiden vorhandenen Werte abfragt; sowas könnte man auch vereinfachen...
Zitat von: john30 am 26 März 2019, 07:19:46
wenn ich das richtig verstehe braucht ihr eine Art Verzeichnis aller verfügbaren Einträge via MQTT, richtig?
Das lässt sich sicher implementieren, ist nur die Frage, wie man das am besten via MQTT kommuniziert. Bspw. bin ich nicht sicher, wie ein Topic mit Teil-Wildcards überhaupt im ebusd ankäme.
Deshalb vielleicht eher ein "/list" mit oder ohne circuit und mit/ohne name?
Hallo John!
Danke das du uns da unterstützen willst!
Eigentlich würde uns die Info genügen wie sie in "ebusctl f -d" enthalten ist
pi@raspberrypi:~ $ ebusctl f -d
430 Hc1HeatCurve = 1.20
430 HwcTempDesired = 57.0
bai CounterStartattempts1 = 29
bai DateTime = nosignal;12:10:22;-.-.-;3.750
bai DeactivationsIFC = 18
bai FanHours = 6275
Ich könnte mir vorstellen, das die Json Strings so wie bei einer Statusabfrage kommen sollten.
Client mosqsub/15308-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status01', ... (240 bytes))
ebusd/bai/Status01 { "0": {"name": "temp1", "value": 48.0}, "1": {"name": "temp1", "value": 40.0}, "2": {"name": "temp2", "value": 4.000}, "3": {"name": "temp1", "value": 42.0}, "4": {"name": "temp1", "value": 45.0}, "5": {"name": "pumpstate", "value": "on"}}
idealerweise wären 2 Listen interessant, einmal alle und einmal nur die wo Daten vorhanden sind, also mit Parameter "-d". Rudolf hat ja autocreate soweit erweitert, dass hier der Wert "complex" die Json Daten in einem Readingnamen zusammensetzt. Mit "simple" würde der erste Teil des Readingnamesn entfallen, also dann nur "1_name", d.h. hier sind wir schon sehr flexibel.
Status01_0_name temp1
Status01_1_name temp1
Status01_2_name temp2
Status01_3_name temp1
Status01_4_name temp1hier wird dann der 1. und 2.Teil des Json Strings zusammen gesetzt, der Hauptgrund war weil bei Status01 und Staus02 sonst gleiche Readings erzeugt wurden und die sich gegenseitig überschreiben. Also wäre dieses Format wohl ideal.
Aber soll sich Beta-User noch melden wie er es sich die "Listenform" vorstellen könnte.
LG
Reinhart
Zitat von: Patrick131184 am 26 März 2019, 07:44:08
Hat jemand bereits ein Dummy/Template erstellt um die Wochenprogramme der Heizung einzustellen?
Man müsste hierzu ja nur 3x von - bis pro Wochentag definieren.
Leider bin ich selber nicht so fit in FHEM das ich das selber erstellen könnte :(
Ich habe sowas in ähnlicher Form schon einmal praktiziert, aber dann alles wieder verworfen weil in der Praxis stellt man das ein einziges mal ein und greift es dann die nächsten Jahre nicht mehr an. Aber wenn die Templates jetzt alle funktionieren kann ich einmal schauen das mit einem Timepicker zu realisieren. Ich habe es mit MQTT noch nicht probiert wie das publishen der Zeit Werte klappt.
LG
@Patrick:
Vielleicht wäre da ein WeekdayTimer auch was, was du dir mal ansehen könntest. Es ist ja nett, wenn die Heizung ein gespeichertes Wochenprogramm hat, aber in der Praxis wäre es ggf. dann halt noch sinnvoll, wenn Feiertage usw. tagesaktuell berücksichtigt werden.
Das ginge u.A. mit dem genannten WeekdayTimer...
@John!
Auch von meiner Seite in herzliches Willkommen & Dank für die Unterstützung@MQTT!
Sorry, dass ich die Förmlichkeit vorhin unterschlagen habe.
M.E. benötigen wir keine neuen Strukturen oder JSON-Verpackungen, sondern die Infos auf dem Weg, wie sie "im wirklichen Leben" auch versendet werden. (Ich hoffe, ich hatte in meinem vorherigen Post einigermaßen erläutert, was ich damit meine).
Wenn das zu Verwirrung führen kann, weil die Daten (im Unterschied zu einer seitherigen get-Anfrage) nicht erst über den Bus aktualisiert werden, sollten wir den Befehl ggf. eben "verstecken"; es geht vorrangig darum, die Topicstruktur zu "sehen", um Geräte anlegen zu können. Dafür täte es auch ein einmaliges Publish...
Gruß, Beta-User
Zitat von: Reinhart am 26 März 2019, 08:37:42
Ich habe sowas in ähnlicher Form schon einmal praktiziert, aber dann alles wieder verworfen weil in der Praxis stellt man das ein einziges mal ein und greift es dann die nächsten Jahre nicht mehr an. .
Das wäre super, mir würde das auch reichen wenn du mir deinen code schicken würdest.
Ich brauche da nicht zwingend ein Template, aber wäre natürlich wünschenswert.
Zitat@Rudi: da das mit den verbotenen Einrückungen ggf. die Übersichtlichkeit extrem reduziert (und an anderer Stelle schon nachgefragt wurde, ob ich das nicht lassen könnte mit den Einrückungen (https://forum.fhem.de/Smileys/default/sad.gif) ): Wäre es viel Aufwand, die Zeilen beim Übernehmen aus dem template "vorzubehandeln" und vor allem einleitende Leerzeichen automatisiert zu löschen?
Wenn es um die erste nicht eingerueckte Zeile in FHEMWEB geht: ich will nicht an den attrTemplate Befehlen rumschnipseln, das fuehrt zu Ueberraschung.
Das Entfernen der Leerzeichen (inkl \n) zwischen Attributname und Attributwert ist auch zu tief in FHEM verankert, das will ich auch nicht aendern. Wenn die eingerueckte Darstellung wirklich ein ernstes Problem ist, dann empfehle ich fuer die Uebersichtlichkeit im template entweder Leerzeilen vor und nach dem Attribut oder eine Kommentarzeile.
Kannst Du bitte ein Beispiel geben, ich bin unsicher, ob ich das Problem begreife.
Vermutlich OT:Wenn man L_01_zigbee2mqtt_bridge auf ein bereits mit mehrzeiligen readingList ausgestattetes Geraet anwendet, dann hagelt es an Fehlermeldungen, weil BASE_TOPIC mit dem Perl-Expression einen mehrzeiligen Wert aufnimmt, z.Bsp.:
Zitat.* LWT
tele
Und da dieser Wert in die diversen Attribute so eingesetzt wird, fuehren die fehlenden \ zu Fehlermeldungen mit "Unknown command tele..."
Zitat von: rudolfkoenig am 26 März 2019, 10:07:56
Wenn es um die erste nicht eingerueckte Zeile in FHEMWEB geht: ich will nicht an den attrTemplate Befehlen rumschnipseln, das fuehrt zu Ueberraschung.
Das Entfernen der Leerzeichen (inkl \n) zwischen Attributname und Attributwert ist auch zu tief in FHEM verankert, das will ich auch nicht aendern.
Das ist m.E. ok so und darf auch gerne so bleiben.
Zitat
Wenn die eingerueckte Darstellung wirklich ein ernstes Problem ist, dann empfehle ich fuer die Uebersichtlichkeit im template entweder Leerzeilen vor und nach dem Attribut oder eine Kommentarzeile.
Im Moment grenzen Leerzeilen die templates optisch gegeneinander ab, aber das mit dem Kommentarzeichen könnte eine Lösung sein.
ZitatKannst Du bitte ein Beispiel geben, ich bin unsicher, ob ich das Problem begreife.
Also aus dem template-code
attr DEVICE readingList \
tele/DEVNAME/LWT:.* LWT\
cmnd/DEVNAME/POWER:.* POWER\
stat/DEVNAME/RESULT:.* { json2nameValue($EVENT) }\
stat/DEVNAME/POWER1:.* POWER1\
stat/DEVNAME/POWER1:on {{'state' => 'opening'}}\
stat/DEVNAME/POWER2:.* POWER2\
stat/DEVNAME/POWER2:on {{'state' => 'closing'}}\
stat/DEVNAME/SHUTTER1:.* state\
stat/DEVNAME/SHUTTER1:.* pct\
tele/DEVNAME/RESULT:.* { json2nameValue($EVENT) }\
tele/DEVNAME/STATE:.* { json2nameValue($EVENT) }\
tele/DEVNAME/SENSOR:.* { json2nameValue($EVENT) }\
tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }\
tele/DEVNAME/UPTIME:.* { json2nameValue($EVENT) }würde dann (list -r) sowas werden:
attr MQTT2_tasmota readingList tele/sonoff/LWT:.* LWT\
cmnd/sonoff/POWER:.* POWER\
stat/sonoff/RESULT:.* { json2nameValue($EVENT) }\
stat/sonoff/POWER1:.* POWER1\
stat/sonoff/POWER1:on {{'state' => 'opening'}}\
stat/sonoff/POWER2:.* POWER2\
stat/sonoff/POWER2:on {{'state' => 'closing'}}\
stat/sonoff/SHUTTER1:.* state\
stat/sonoff/SHUTTER1:.* pct\
tele/sonoff/RESULT:.* { json2nameValue($EVENT) }\
tele/sonoff/STATE:.* { json2nameValue($EVENT) }\
tele/sonoff/SENSOR:.* { json2nameValue($EVENT) }\
tele/sonoff/INFO.:.* { json2nameValue($EVENT) }\
tele/sonoff/UPTIME:.* { json2nameValue($EVENT) }Keine einrückenden Leerzeichen mehr. Entsprechendes dann für bridgeRegexp, getList und setList. Ist das verständlich erklärt? (Anmerkung: mich selbst stört das eigentlich gar nicht so, deswegen gebe ich an der Stelle auch nur wieder, was ich anderswo verstanden hatte...)
ZitatVermutlich OT:Wenn man L_01_zigbee2mqtt_bridge auf ein bereits mit mehrzeiligen readingList ausgestattetes Geraet anwendet, dann hagelt es an Fehlermeldungen, weil BASE_TOPIC mit dem Perl-Expression einen mehrzeiligen Wert aufnimmt, z.Bsp.:Und da dieser Wert in die diversen Attribute so eingesetzt wird, fuehren die fehlenden \ zu Fehlermeldungen mit "Unknown command tele..."
Ist hier wirklich OT, aber trotzdem kurz... Das muß ich mir anschauen, vermutlich muß da eine eingeschränktere Regex hin. Würde mal mit
m,[^:]+:([^/]+)[/].*:.*$, an den Start gehen?
ZitatIst das verständlich erklärt?
Ja.
Zitatmich selbst stört das eigentlich gar nicht so
Mich auch nicht, ich empfehle "lassen wie es ist" :)
Zitatm,[^:]+:([^/]+)[/].*:.*$,
Geht genausowenig.
Um zu helfen, muesste ich verstehen, was man will.
Zitat von: rudolfkoenig am 26 März 2019, 11:25:18
Mich auch nicht, ich empfehle "lassen wie es ist" :)
Ich hätte das Thema auch nicht angesprochen, wenn nicht Reinhart hier berichtet hätte, dass das Probleme mit dem ebus-Dämon verursacht. Ich kann mir das zwar nach wie vor nicht recht erklären, warum das so sein sollte, aber es wurde eben hier getestet. Andererseits: Das betrifft einen speziellen Einzelfall, von daher sollte/kann man das da dann auch "lokal" abfangen...
Zitat
Geht genausowenig.
Um zu helfen, muesste ich verstehen, was man will.
Hmm, sollten wir vermutlich in dem Zigbee-Thread weiterdiskutieren, geht ja um die Topic-Struktur wie hier beschrieben: https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html.
Also: gibt es "irgendwo" einen zigbee2mqtt-Dienst, der sich bei einem auf autocreate gestellten MQTT2-IO meldet, wird erst mal ein Device angelegt. Die readingList dürfte dann entweder mit "zigbee2mqtt/bridge/state" (oder anderen "...bridge/+"-Topics beginnen, oder es ist eben gleich eines der "dahinterliegenden" Devices, wobei das 2. Element entweder mit "0x" beginnt (kein "friendly name" vergeben), oder mit einem Freitext, den der user über die Konfigurationsfile des Diensts (configuration.yaml) definiert hat (vergleichbar vielleicht mit einem "alias" für FHEMWEB). Was wir brauchen, ist eben der erste Teil der topic-Struktur, weil nur das (einigermaßen) "verläßlich" ist.
Ich kann das vermutlich erst am WE mal versuchen nachzustellen, was das für ein Fehler ist usw.. So wie ich das verstanden habe, tritt das (nur?) auf, wenn man das template auf ein ganz anderes Device mit einer unpassenden readingList anwendet, oder?
ZitatHmm, sollten wir vermutlich in dem Zigbee-Thread weiterdiskutieren
Gut, bitte verlinken, und mir da ein Beispiel geben mit "das habe ich" und "das will ich".
ZitatSo wie ich das verstanden habe, tritt das (nur?) auf, wenn man das template auf ein ganz anderes Device mit einer unpassenden readingList anwendet, oder?
Es tritt auf, wenn man das template auf irgendetwas anwendet, was ein readingsList mir mehreren Zeilen hat, z.Bsp. zweimal hintereinander auf ein leeres Device.
Eine kurze Frage in die Runde:
Ich versuche mich gerade in ein eBus-MQTT-Template für meine Lüftungsanlage, da ich sowieso gerade dabei bin, von GAEBUS auf MQTT2 zu wechseln.
Nun ist mir dabei jedoch etwas aufgefallen, wo ich kurz einen Tipp von euch benötige.
Ich möchte in einem MQTT2_DEVICE die Circuit-Topics vom Global-Topic trennen und habe dies mit dem Daemon-Splitter auch umsetzen können. Nun viel mir dabei auf, dass zwar alle Readings und Attribute per autocreate angelegt wurden. Aber die Readings werden nicht oder merkwürdig sporadisch aktualisiert.
Ich habe meine alte eBus-Lösung vorerst abgeklemmt, damit nicht dadurch das "Read" ausgelöst wird.
In meiner ebus-Config habe ich das Polling für alle Werte zwischen r1 und r9 aktiviert. Das Polling-Intervall ist auf 10 Sekunden. Und gewissen Werte werden sogar per Broadcast im 5 Sekunden-Takt geschickt. Aber scheinbar verbleiben die "gepollten Reads" im ebusd-Cache und werden nicht über MQTT an mein MQTT2_DEVICE übertragen. Auch weder "ebusctl read xyz" noch "ebusctl read -f xyz" haben einen Einfluss auf die MQTT-Übertragung.
Ist es so, dass ich wirklich manuell ein GET durchführen muss?
So wurde es hier im Thread, glaube ich, auch von Reinhart empfohlen.
Nachtrag
Ich denke die Antworten hier gefunden zu haben: https://forum.fhem.de/index.php/topic,29737.msg905181.html#msg905181
Außerdem: Ich bin hier wohl im falschen Thread gelandet. Sorry.
Zitat von: Beta-User am 26 März 2019, 08:47:22
M.E. benötigen wir keine neuen Strukturen oder JSON-Verpackungen, sondern die Infos auf dem Weg, wie sie "im wirklichen Leben" auch versendet werden. (Ich hoffe, ich hatte in meinem vorherigen Post einigermaßen erläutert, was ich damit meine).
Wenn das zu Verwirrung führen kann, weil die Daten (im Unterschied zu einer seitherigen get-Anfrage) nicht erst über den Bus aktualisiert werden, sollten wir den Befehl ggf. eben "verstecken"; es geht vorrangig darum, die Topicstruktur zu "sehen", um Geräte anlegen zu können. Dafür täte es auch ein einmaliges Publish...
aus meiner Perspektive würde ich jetzt ein "/list" implementieren, das auf Toplevel und Gerätelevel abgesetzt werden kann, also:
- /ebusd/list
- /ebusd/ehp/list
Als Antwort kämen dann asynchron alle Einträge unter dem angegebenen Level (also ohne "/list").
Als nächstes könnte man noch den Request Topic Inhalt verwenden um bspw. nur auf die Einträge einzuschränken, für die auch bereits Daten vorliegen.
BTW: Das gleiche ließe sich eigentlich ohne jegliche Code-Änderung durch Verwendung von --mqttretain (https://github.com/john30/ebusd/wiki/2.-Run#mqtt-options) erreichen, hätte aber den Nachteil, dass sämtliche Topics bis zum nächsten Update quasi festgeschrieben sind.
Vorab zu Retain (ich bin da auch nicht ganz durch, kann also auch "verbesserungsfähig sein"):
- Für das Ziel der Erstellung der Devices ist das Alter der Info egal; da dann auch eine Wildcard-Abfrage zielführend wäre, ist das evtl. eine gute Sache.
- Problem des Daten-Alters: An sich korrekt, aber so richtig schwierig wird das erst, wenn der User die Daten wiederholt abfragt und dabei annimmt, die Daten wären aktualisiert. Da wären wir aber ggf. bei "last will"-Themen.
- Weiter ist mir nicht klar, ob denn dann davon auszugehen wäre, dass der Broker alle verfügbaren Daten hat. So wie ich das bisher verstanden habe, werden viele Datensätze erst dann an den Broker geschickt, wenn sie abgefragt werden. Wenn das nicht so ist, und der Broker immer nach und nach die Daten bekäme, wäre das auch ok. Dann müßte man dem User nur erklären, dass er eben erst mal eine Zeit warten muß bzw. wie lange es ggf. Sinn macht zu warten.
list:
- Wenn man eine konkrete Abfrage macht, ist "mir" das Kommando im Prinzip egal. Mit einem /list kann ich gut leben. Ergänzend zu dem, was ich bereits geschrieben habe: Auch "dummy"-Rückgaben wären für die Strukturabfrage ok, es sollte aber das jeweilige Rückgabeformat (JSON/nicht-JSON) eingehalten sein und ggf. Datenbenennungen innerhalb des JSON verwendet werden, die auch sonst üblich sind; sonst bekommen wir unnötige zusätzliche Readings (reichen würde aber ein JSON-Element mit dummy-Wert). (bitte Nachfragen, wenn das zu kryptisch sein sollte).
- Ich gehe davon aus, dass bei der Toplevel-Abfrage dann alles käme (in MQTT: ebusd/#, nicht nur ebusd/+)?
"ehp":
Ich habe eben das erste Mal gesehen, dass es neben "bai" auch weitere Geräte mit nicht-nummersichen Benennungen zu geben scheint. Das wäre für die bridgeRegexp wichtig, die wäre entsprechend zu erweitern. Gibt es da viele Varianten bzw. welche?
Hallo John!
ich finde "list" als gute Möglichkeit und ist auch sprechend!
Weil ich gerade vor dem Problem sitze einen Wochentimer zu erstellen, stehe ich vor dem Problem wie man mit MQTT den String senden muss.
pi@raspberrypi:~ $ ebusctl w -c 430 ccTimer.Monday '04:00;22:00;22:00;22:00;22:00;22:00;Mo-So'
done
pi@raspberrypi:~ $ ebusctl r -f ccTimer.Monday
04:00;22:00;22:00;22:00;22:00;22:00;Mo-So
so geht es direkt mit ebusctl, erste Zeit auf 04:00 gesetzt und es steht bei der nächsten Abfrage schon im Register.
Befehl MQTT2: set ebusMQTT publish ebusd/430/ccTimer.Monday/get
Client mosqsub/2877-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/ccTimer.Monday', ... (284 bytes))
ebusd/430/ccTimer.Monday { "0": {"name": "from", "value": "04:00"}, "1": {"name": "to", "value": "22:00"}, "2": {"name": "from", "value": "22:00"}, "3": {"name": "to", "value": "22:00"}, "4": {"name": "from", "value": "22:00"}, "5": {"name": "to", "value": "22:00"}, "6": {"name": "daysel", "value": "Mo-So"}}
eine Abfrage mit MQTT2 ergibt diesen Json String, auch die vorher gesetzte 04:00 ist schon drinnen.
Ich habe nun mit setList einen Weektimer gebastelt der auch soweit funktioniert. Ich kann jeden beliebigen Outputstring ( MQTT2 set ) erstellen, aber wie muss der aussehen?
set ebusMQTT publish ebusd/430/ccTimer.Monday/set {06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr}
set ebusMQTT publish ebusd/430/ccTimer.Monday/set "06:00,22:00,22:00,22:00,22:00,22:00,Mo-Fr"
set ebusMQTT publish ebusd/430/ccTimer.Monday/set 06:00,22:00,22:00,22:00,22:00,22:00,Mo-Fr
set ebusMQTT publish ebusd/430/ccTimer.Monday/set {"0":"05:00","1":"06:00","2":"07:00","3":"08:00","4":"09:00","5":"10:00","6":"Mo-So"}
hier so meine Varianten, die zwar keinen Fehler verursachen aber auch keine Wirkung zeigen. Die Befehle sind in der Mosquitto Konsole aber sauber sichtbar und werden zumindest als empfangen bestätigt.
dieses Kommando "set ebusMQTT publish ebusd/430/ccTimer.Monday/set {"0":"05:00","1":"06:00","2":"07:00","3":"08:00","4":"09:00","5":"10:00","6":"Mo-So"}" wird dann so gelogt.
Client mosqsub/6525-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/ccTimer.Monday/set', ... (85 bytes))
ebusd/430/ccTimer.Monday/set {"0":"05:00","1":"06:00","2":"07:00","3":"08:00","4":"09:00","5":"10:00","6":"Mo-So"}
wenn ich den ganzem Json String nehme geht es natürlich auch nicht.
{ "0": {"name": "from", "value": "06:00"}, "1": {"name": "to", "value": "22:00"}, "2": {"name": "from", "value": "22:00"}, "3": {"name": "to", "value": "22:00"}, "4": {"name": "from", "value": "22:00"}, "5": {"name": "to", "value": "22:00"}, "6": {"name": "daysel", "value": "Mo-So"}}
Vielleicht hat jemand eine Idee wie der MQTT2 String mit den 7 Timern (Felder 0-6) aussehen sollte!
ebusctl braucht ja keine Feldangabe und differenziert nach der Reihenfolge der ";".
LG
Reinhart
Zitat von: Beta-User am 27 März 2019, 09:15:47
- Problem des Daten-Alters: An sich korrekt, aber so richtig schwierig wird das erst, wenn der User die Daten wiederholt abfragt und dabei annimmt, die Daten wären aktualisiert. Da wären wir aber ggf. bei "last will"-Themen.
das Alter der Daten ist mit retain natürlich beliebig.
Last Will wird von ebusd derzeit nur für global/running genutzt. Recht viel mehr macht aus meinen Augen keinen Sinn.
Zitat von: Beta-User am 27 März 2019, 09:15:47
- Weiter ist mir nicht klar, ob denn dann davon auszugehen wäre, dass der Broker alle verfügbaren Daten hat. So wie ich das bisher verstanden habe, werden viele Datensätze erst dann an den Broker geschickt, wenn sie abgefragt werden. Wenn das nicht so ist, und der Broker immer nach und nach die Daten bekäme, wäre das auch ok. Dann müßte man dem User nur erklären, dass er eben erst mal eine Zeit warten muß bzw. wie lange es ggf. Sinn macht zu warten.
natürlich nicht, denn die Daten trudeln ja nur ein, wenn sie auch ein Device abfrägt (inkl. ebusd). Die Menge der an den Broker gepublishten Messages ist also ziemlich undefiniert. Man kann zwar darauf Einfluss nehmen, aber ich würde davon abraten bspw. beim ebusd Start alle bekannten Nachrichten aktiv abzufragen.
Zitat von: Beta-User am 27 März 2019, 09:15:47
- Wenn man eine konkrete Abfrage macht, ist "mir" das Kommando im Prinzip egal. Mit einem /list kann ich gut leben. Ergänzend zu dem, was ich bereits geschrieben habe: Auch "dummy"-Rückgaben wären für die Strukturabfrage ok, es sollte aber das jeweilige Rückgabeformat (JSON/nicht-JSON) eingehalten sein und ggf. Datenbenennungen innerhalb des JSON verwendet werden, die auch sonst üblich sind; sonst bekommen wir unnötige zusätzliche Readings (reichen würde aber ein JSON-Element mit dummy-Wert). (bitte Nachfragen, wenn das zu kryptisch sein sollte).
klar.
Zitat von: Beta-User am 27 März 2019, 09:15:47
- Ich gehe davon aus, dass bei der Toplevel-Abfrage dann alles käme (in MQTT: ebusd/#, nicht nur ebusd/+)?
nicht ganz, es käme alles zu diesem Zeitpunkt bekannte unterhalb des parent (also in subscribe Nomenklatur "ebusd/#"). Durch den Device Scan Vorgang in ebusd kann es auch sein, dass sich die Liste der Devices nach ein paar Minuten (oder auch Stunden je nach ebusd Konfiguration) erweitert.
Zitat von: Beta-User am 27 März 2019, 09:15:47
"ehp":
Ich habe eben das erste Mal gesehen, dass es neben "bai" auch weitere Geräte mit nicht-nummersichen Benennungen zu geben scheint. Das wäre für die bridgeRegexp wichtig, die wäre entsprechend zu erweitern. Gibt es da viele Varianten bzw. welche?
Die meisten Benennungen sind nicht-numerisch. Die potentielle Liste ist jetzt schon recht lang und das kann noch mehr werden:
140, 350, 360, 36p, 370, 392, 400, 430, 470, 700, bai, broadcast, cc, e7f, ehp, f37, f43, f47, general, hc, heb, hep, hmu, hwc, mc, mc.3, mc.4, mc.5, mc.6, mc.7, omu, omu.1, pms, rcc, rcc.1, rcc.3, rcc.4, rcc.5, rcc.6, rcc.7, sc, scan, sdr_p, ui, uih, v65, v81, v81.1, v81.3, v81.4, v81.5, v81.6, v81.7, vd2, vd3, vd4, vd6, vl8, vl9, vr_70, vr_71, zeo
Zitat von: Reinhart am 27 März 2019, 09:48:32
Ich habe nun mit setList einen Weektimer gebastelt der auch soweit funktioniert. Ich kann jeden beliebigen Outputstring ( MQTT2 set ) erstellen, aber wie muss der aussehen?
set ebusMQTT publish ebusd/430/ccTimer.Monday/set {06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr}
set ebusMQTT publish ebusd/430/ccTimer.Monday/set "06:00,22:00,22:00,22:00,22:00,22:00,Mo-Fr"
set ebusMQTT publish ebusd/430/ccTimer.Monday/set 06:00,22:00,22:00,22:00,22:00,22:00,Mo-Fr
set ebusMQTT publish ebusd/430/ccTimer.Monday/set {"0":"05:00","1":"06:00","2":"07:00","3":"08:00","4":"09:00","5":"10:00","6":"Mo-So"}
/set erwartet derzeit das gleiche Format wie ebusctl, also wäre richtig:
set ebusMQTT publish ebusd/430/ccTimer.Monday/set "06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr"
Zitat von: john30 am 29 März 2019, 07:33:07
/set erwartet derzeit das gleiche Format wie ebusctl, also wäre richtig:
set ebusMQTT publish ebusd/430/ccTimer.Monday/set "06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr"
@Reinhart+TomLee: Wenn ihr das vertemplatet, würde ich ein set vorschlagen, das dann zwei Elemente benötigt. Den Wochentag ($EVTPART1) und die eigentliche Temperaturliste. Siehe z.B. x_configuration in A_02b_tasmota_2ch_shutter_invert_1
Zitat
nicht ganz, es käme alles zu diesem Zeitpunkt bekannte unterhalb des parent (also in subscribe Nomenklatur "ebusd/#"). Durch den Device Scan Vorgang in ebusd kann es auch sein, dass sich die Liste der Devices nach ein paar Minuten (oder auch Stunden je nach ebusd Konfiguration) erweitert.
So war die Frage gemeint, und imo sollte das ausreichen. Dann muß man dem user halt nur erklären, dass es ggf. dauern kann, je nachdem, wie lange der ebusd schon am laufen ist, bis "alles" verfügbar ist.
Hieße anders gewendet: es braucht eine Möglichkeit für den user, das z.B. am nächsten Tag nochmal anfragen zu können. Lösungen: entweder ein setter am ebusd-Gerät (für toplevel), oder ein template, das dann nur den publish macht => eure Meinung?
(Ich würde zum set tendieren, auch wenn das eigentlich für den User zu zugänglich ist. "set ... getKnownDevicesList"? Das ist wenigstens so seltsam, dass der eine oder andere sich evtl. fragt, was das sein soll ::) ).
Die Liste ist in der Tat lang, läßt sich aber durch etwas regex sicher eindampfen. Interessanter noch wäre die Frage, ob bestimmte Elemente zusammengefaßt werden sollten oder getrennt gehalten. Im Moment habe ich bai und broadcast mal auf dasselbe MQTT2-Gerät (bai) gemappt, auf die Frage, ob das schlau war, habe ich bis dato aber noch keine abschlägige Antwort erhalten...
Die nummerischen getrennt zu halten ist vermutlich auch eine gute Idee. Dasselbe dürfte für alles andere gelten, was wirklich für eine Baugruppe steht.
Aber was ist mit Dingen wie "general" und "scan"?
Zitat von: Beta-User am 29 März 2019, 08:08:01
Die Liste ist in der Tat lang, läßt sich aber durch etwas regex sicher eindampfen. Interessanter noch wäre die Frage, ob bestimmte Elemente zusammengefaßt werden sollten oder getrennt gehalten. Im Moment habe ich bai und broadcast mal auf dasselbe MQTT2-Gerät (bai) gemappt, auf die Frage, ob das schlau war, habe ich bis dato aber noch keine abschlägige Antwort erhalten...
im Moment sind die broadcast noch sehr allgemein gehalten, da für den kompletten "Vaillant" Namespace gültig. Das könnte sich aber in Zukunft mal ändern und gilt vielleicht auch nicht für andere Hersteller.
Anyway, ich denke für den Moment passt die Zusammenfassung auf ein anderes Gerät. Nur: wie macht ihr das, wenn es keine bai gibt, sondern bspw. eine ehp? Das spricht in meinen Augen doch wieder eher für eine Trennung, da die Benennung des Heizgeräts nicht so einfach erkennbar ist.
Zitat von: Beta-User am 29 März 2019, 08:08:01
Die nummerischen getrennt zu halten ist vermutlich auch eine gute Idee. Dasselbe dürfte für alles andere gelten, was wirklich für eine Baugruppe steht.
Aber was ist mit Dingen wie "general" und "scan"?
Inwiefern getrennt halten? Was macht das denn für einen Unterschied? Ich würde hier keine Unterscheidung zwischen numerischen und alphanum. machen.
general kann man erstmal vergessen und scan ist eine rein ebusd interne Geschichte. Hierüber werden die gescannten Geräte identifiziert.
OK, dann arbeite ich den Splitter um, dass er alles auch unterscheidet und (erst mal!) in separate Devices packt, was unterschiedlich ist. Das sollte recht einfach sein...
Wenn der user dann danach die Zusammenfassung doch sinnvoll findet, muß er eben die readingList an dem Gerät anfassen, das die Daten final enthalten soll.
Was eventuell nicht so einfach ist, sind die Punkte in der topic-Struktur. Da wäre es gut, wenn ihr jemanden zum Testen motivieren könntet, der "sowas" hat (vielleicht funktioniert das auch reibungslos, mal schauen).
Zitat von: john30 am 29 März 2019, 07:33:07
/set erwartet derzeit das gleiche Format wie ebusctl, also wäre richtig:
set ebusMQTT publish ebusd/430/ccTimer.Monday/set "06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr"
Danke John, so eine ähnliche Antwort habe ich befürchtet, denn weder Mosquitto noch MQTT2_Server erlaubt ein Semikolon ";" beim set Befehl als Feldtrenner.
Das Kommando in der Eingabezeile ergibt: set ebusMQTT publish ebusd/430/hcTimer.Monday/set 06:00;22:00;22:00;22:00;22:00;22:00;Mo-So
Unknown command 22:00, try help.
Unknown command 22:00, try help.
Unknown command 22:00, try help.
Unknown command 22:00, try help.
Unknown command 22:00, try help.
Unknown command Mo-So, try help.Meine Versuche mit Klammern habe auch keinen Erfolg gebracht, das Semikolon wird sofort als falscher Trenner erkannt.
LG
Reinhart
Hmm, kannst du mal versuchen, das in einfache Anführungszeichen zu packen? Also
set ebusMQTT publish ebusd/430/ccTimer.Monday/set '06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr'
oder
set ebusMQTT publish ebusd/430/ccTimer.Monday/set '"06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr"'
Zitat von: Beta-User am 29 März 2019, 14:52:01
set ebusMQTT publish ebusd/430/ccTimer.Monday/set '06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr'
das sollte den Trick tun, liegt einfach an der shell, die ";" als Trenner für weitere Kommandos nutzt. Evtl. backslash vor jedes Semicolon setzen
Danke für eure Tipps, aber beim ersten ";" wird rigoros abgebrochen. Ich habe jetzt alle Kombinationen durch, hier ein Beispiel.
set ebusMQTT publish ebusd/430/hcTimer.Monday/set '"06:00\;22:00\;22:00\;22:00\;22:00\;22:00\;Mo-Fr"'
Client mosqsub/5521-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/hcTimer.Monday/set', ... (8 bytes))
ebusd/430/ccTimer.Monday/set '"06:00\
Schade, denn mit ECMD funktioniert das problemlos. Nur ich bewerte das nicht so hoch, weil die Timer habe ich den letzten 9 Jahren nur 1x an der Calormatic verstellt und mit ebusctl funktioniert es ohnehin. Es gibt auch noch ein zweites kleines Problem, selbst mit ebusctl kann der "daysel" (Tagesselektor) nicht gesetzt werden kann. Das kann ich aber noch an der Calormatic verstellen und mitloggen was da passiert.
Ich deute die Fehler so, wenn Mosquitto als Logger den String nur bis zum Auftreten des ersten Semikolons sieht, dann werden die bereits vom Modul MQTT2 (egal ob Server oder Client) schon gefiltert und gar nicht erst gesendet. Es kommt ja in Fhem auch sofort die Fehlermeldung beim ersten Semikolon. Ich könnte natürlich den String in ein File schreiben (ohne MQTT), das dann ersetzen und dann erst bereinigt versenden. Aber sowas finde ich mit der Kirche ums Kreuz und produziert unnötig Code in der myUtils.
LG
ZitatDanke für eure Tipps, aber beim ersten ";" wird rigoros abgebrochen. Ich habe jetzt alle Kombinationen durch, hier ein Beispiel.
FHEM bricht Befehle am Strichpunkt (;), um sie zu schuetzen muss man diese verdoppeln (siehe https://fhem.de/commandref_modular.html#command (https://fhem.de/commandref_modular.html#command))
Rudolf du bist ein wahrer König, das ist die Lösung!
In der Fhem Eingabezeile klappt das nun sofort, aber innerhalb eines "notify" wo ich den String erst für die Ausgabe zusammen setze, versagt diese Methode. Ich habe es dann mit 2 hintereinander folgenden " . chr(59) . chr(59)" gelöst. Ich editiere normalerweise mit dem eingebauten Fhem Editor direkt am Attribut, wo man ohnehin nur ein ";" sieht. Dieser Auszug hier ist wegen dieses Effektes direkt aus der fhem.cfg.
Hier bei hcTimer.Monday arbeite ich mit 2 chr(59) und bei hcTimer.Tuesday mit ";;"
define DayWrite notify schreiben {fhem "set ebusMQTT publish ebusd/430/hcTimer.Monday/set " . ReadingsVal("TimeMo","HHMM1m",0) . chr(59) . chr(59) . ReadingsVal("TimeMo","HHMM2m",0) . chr(59) . chr(59) . ReadingsVal("TimeMo","HHMM3m",0) . chr(59) . chr(59) . ReadingsVal("TimeMo","HHMM4m",0) . chr(59) . chr(59) . ReadingsVal("TimeMo","HHMM5m",0) . chr(59) . chr(59). ReadingsVal("TimeMo","HHMM6m",0) . chr(59) . chr(59) . ReadingsVal("TimeMo","HHMM7m",0);;\
fhem "set ebusMQTT publish ebusd/430/hcTimer.Tuesday/set " . ReadingsVal("TimeDi","HHMM1t",0) . ";;" . ReadingsVal("TimeDi","HHMM2t",0) . ";;" . ReadingsVal("TimeDi","HHMM3t",0) . ";;" . ReadingsVal("TimeDi","HHMM4t",0) . ";;" . ReadingsVal("TimeDi","HHMM5t",0) . ";;" . ReadingsVal("TimeDi","HHMM6t",0) . ";;" . ReadingsVal("TimeDi","HHMM7t",0);;\
Log 1, "Zeitprog=" . ReadingsVal("TimeMo","HHMM1m",0) . ";;" . ReadingsVal("TimeMo","HHMM2m",0) . ";;" . ReadingsVal("TimeMo","HHMM3m",0) . ";;" . ReadingsVal("TimeMo","HHMM4m",0) . ";;" . ReadingsVal("TimeMo","HHMM5m",0) . ";;" . ReadingsVal("TimeMo","HHMM6m",0) . ";;" . ReadingsVal("TimeMo","HHMM7m",0);;}
und hier das Log vom Mosquitto, Montag mit "chr59" klappt tadellos, beim Dienstag klappt es mit den beiden ;; nicht und es gibt dann Abriss nach dem ersten ";"
Client mosqsub/21565-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/hcTimer.Monday/set', ... (41 bytes))
ebusd/430/hcTimer.Monday/set 03:00;22:00;22:00;22:00;22:00;22:00;Mo-So
Client mosqsub/21565-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/hcTimer.Tuesday/set', ... (5 bytes))
ebusd/430/hcTimer.Tuesday/set 04:00
Client mosqsub/21565-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/hcTimer.Monday', ... (284 bytes))
ebusd/430/hcTimer.Monday { "0": {"name": "from", "value": "03:00"}, "1": {"name": "to", "value": "22:00"}, "2": {"name": "from", "value": "22:00"}, "3": {"name": "to", "value": "22:00"}, "4": {"name": "from", "value": "22:00"}, "5": {"name": "to", "value": "22:00"}, "6": {"name": "daysel", "value": "Mo-So"}}
Aber Hauptsache es klappt nun und ich kann weiter machen. Zeiten können nun gesetzt werden, aber der Tagesselektor macht noch eBus spezifische Probleme. Wenn das auch klappt, kann ich mich erst übers Template machen.
Die Problematik die ich bei der Erstellung habe, sind 49 Eingabefelder mit setList, dich ich keinesfalls 49 mal einzeln senden will, deshalb baue ich erst den String zusammen und drück dann eine Taste zum Senden, alle 7 Tage werden erst dann nacheinander geschrieben. Vorerst teste ich mit 2 Tagen, dann erweitere ich erst auf alle 7.
LG
ZitatIn der Fhem Eingabezeile klappt das nun sofort, aber innerhalb eines "notify" wo ich den String erst für die Ausgabe zusammen setze, versagt diese Methode.
Fuer jede "Klammer" muss man die Strichpunkte verdoppeln, ist aber eigentlich ein bekanntes "Problem".
Ist bei vielen "Klammern" (dein Befehl befehl im at was per notify definiert wird muesste jeweils 8 Strichpunkte haben), nicht sehr uebersichtlich, und deswegen empfehle in solchen Faellen moeglichst viel nach myUtils.pm zu verlagern, da kann man das verdoppeln sparen.
Natuerlich hat man aber auch in myUtils.pm das gleiche Problem, wenn man fhem("XXX") aufruft.
@rudolfkoenig
Danke für die Erklärung. Damit ich auf Nummer sicher bin bleib ich dann bei den chr(59).
@john
ich habe das Template soweit fertig und ich kann alle 7 Tage einstellen. Probleme habe ich allerdings mit dem Tageselektor "daysel", der Rest funktioniert aber fehlerfrei.
Konsolenbefehl
pi@raspberrypi:~ $ ebusctl w -c 430 hctimer.monday '02:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr'
done
pi@raspberrypi:~ $ ebusctl r -f hctimer.monday
02:00;22:00;22:00;22:00;22:00;22:00;Mo-So
ich setzte daysel auf "Mo-Fr" und erhalte bei der nächsten Abfrage "Mo-So", also den alten Wert. Das passiert schon in der Konsole.
Logfile ebusd
2019-03-31 20:01:10.316 [update error] unable to parse read 430 hcTimer.Monday from ff15b5150900000c848484848401 / 00: ERR: invalid position
2019-03-31 20:01:10.316 [main notice] write 430 hcTimer.Monday: done
2019-03-31 20:02:18.281 [update notice] sent read 430 hcTimer.Monday QQ=ff: 02:00;22:00;22:00;22:00;22:00;22:00;Mo-So
und hier die Logs dazu mit der Fehlermeldung "invalid position", der Rest wird aber geschrieben, nur der "daysel" nicht. Für mich bedeutet dies, das das Csv mit der Feldbeschreibung nicht überein stimmt. Ich kann aber nirgends einen Fehler sichten (timerhc.inc oder _templates.csv).
daysel,UCH,0=selected;1=Mo-Fr;2=Sa-So;3=Mo-So,,Tage
Ebenfalls getestet mit numerischem daysel (0,1,2,3), auch ohne Erfolg.
das ergibt dann so eine widersprüchliche Anzeige wie im Bild. Montag "Mo-So" und Samstag zusätzlich mit "Sa-So" und keine kann geändert werden. An der Calormatic aber schon.
Kannst du dir vorstellen, was da nicht passt? Im MQTT2 kann der Fehler nicht sein, aber produziert natürlich die gleichen Meldungen weil sie schon von der Schicht darunter kommen.
LG
Zitat von: Reinhart am 31 März 2019, 20:35:12
Konsolenbefehl
pi@raspberrypi:~ $ ebusctl w -c 430 hctimer.monday '02:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr'
done
pi@raspberrypi:~ $ ebusctl r -f hctimer.monday
02:00;22:00;22:00;22:00;22:00;22:00;Mo-So
ich setzte daysel auf "Mo-Fr" und erhalte bei der nächsten Abfrage "Mo-So", also den alten Wert. Das passiert schon in der Konsole.
ich vermute, dass die 430 so schlau ist, nur die wirklich geänderten Tage ins EEPROM zu schreiben. Schau mal nach, wir der Timer für einen der beiden wirklich geänderten Tage aussieht, also Samstag oder Sonntag.
Zitat von: Reinhart am 31 März 2019, 20:35:12
2019-03-31 20:01:10.316 [update error] unable to parse read 430 hcTimer.Monday from ff15b5150900000c848484848401 / 00: ERR: invalid position
2019-03-31 20:01:10.316 [main notice] write 430 hcTimer.Monday: done
das ist ein Fehler in der Definition, den hatte ich übersehen. Hier besteht das Problem mit allen Timern aus der b515 Ecke, dass die Lese- und Schreibrichtung nicht klar unterschieden werden können. Deshalb interpretiert ebusd den write als read und kommt dann natürlich nicht mit der Struktur klar.
Zur Korrektur müsste man für den Moment als ZZ in der Konfiguration die 10 notieren, dann wäre das klar unterschieden.
Langfristig muss ich die Unterscheidung bei Abwesenheit einer ZZ Angabe ebusd beibringen (https://github.com/john30/ebusd/issues/278).
@John
Danke fürs Nachschauen, habe zwar in der timerhc.inc mal probeweise den ZZ auf 10 (dez) geändert hat aber keine Wirkung gezeigt.
r;w,,hcTimer.Monday,Zeitfenster Montag,,10,,0000,,,timer,,,
Auf jeden Fall sieht das so aus als hätte das noch nie wer probiert, sonst hätte man das schon früher merken müssen. Ist aber jetzt fürs Template egal, das brauche ich somit nicht mehr ändern man muss es halt vermerken das der "daysel" momentan noch nicht funktioniert. Ich wollte zwar den Gegentest direkt auf der 430 durchführen und auch wirklich unterschiedliche Zeiten vorgegeben, aber eine b515 sehe ich nicht im Log, obwohl bei erneutem Einlesen die Änderung (auch vom template erzeugten Timer) sofort sichtbar ist.
@all
Vielleicht kann auch TomLee das Template einmal auf seiner 700 testen.
Ach ja, ich habe die Zeiteinstellung jetzt nur für "Heizkreis" gemacht (TimerHC), die anderen wie DHW, Zirkulationspumpe oder Kühler bedürfen einer geringen Änderung oder ich mache noch ein zusätzliches Auswahlfeld für den Gerätetyp, keine Ahnung ob sowas dann überhaupt gebraucht wird.
Ich benötige so einen Timer nicht, der kann den ganzen Tag auf "ein" sein, denn ich steuere alles über ein Relais an dem Thermostatkontakt (Sommer/Winterbetrieb) und zusätzlich über die Heizkurve (Nacht ist bei mir Heizkurve 0.2-0.6). Dieser Timer ist ja rein für die Nachtabsenkung gedacht die bei mir zu 100% Fhem übernimmt. Sollte Fhem ausfallen, dann kann der Timer in der Nacht noch abschalten, weil der Fhem auf jeden Fall überschreibt.
Kurze Beschreibung der Funktionsweise des Template.
Es gibt 3x Ein und 3x Aus Felder und eine Vorbelegung der Tagesauswahl. Wird die Tagesauswahl bei Montag auf "Mo-So" eingestellt, dann sind alle nachfolgenden Tagesfelder ohne Wirkung und nicht notwendig. Die Einstellung kann ansonsten für jeden Tag (also 7x) einzeln durchgeführt werden. Der setList für die Zeitvorgaben ist nicht im MQTT2 Device, sondern in einem Dummy damit nicht jede einzelne Änderung zu einem MQTT2 "set" führt. Am Ende der Gui für die Tagestimer gibt es 2 Taster, einer für "Einlesen" aller 7 Timer vom eBus und eine Taste zum "Schreiben" aller durchgeführten Zeiten (7 Felder pro Tag und x 7 Wochentage) auf einmal. D.h. hier muss man aufpassen, nur eine Änderung der Zeiten in den Feldern schreibt diese NICHT automatisch zurück. Da aber für jedes Eingabefeld eine Variable die Zeitvorgabe speichert, kann man auch noch später "schreiben" drücken.
Somit dürfte auch klar sein, das man bei "lesen" oder "schreiben" ein paar Sekunden warten muss bis das wirklich erledigt ist und am Heizgerät angekommen ist.
Die Zeit Readings müssen (und sollten es auch nicht) nicht separat zyklisch vom Bus abgefragt werden, diese werden automatisch durch "einlesen" spontan vom eBus geholt und in die Eingabefelder kopiert! Wer ein schnelles Auge hat, der sieht wie sich die Felder von Montag bis Sonntag füllen.
LG
@Reinhart
Wo hast du den das Template hinterlegt ? hier (https://forum.fhem.de/index.php/topic,79600.msg878716.html#msg878716) ist es nicht dabei.
edit:
doch ist dabei, hatte ein vorheriges mqtt2.ebus-1.template nach AttrTemplate geschoben.
Zitat von: john30 am 29 März 2019, 07:28:58
Die potentielle Liste ist jetzt schon recht lang und das kann noch mehr werden:
140, 350, 360, 36p, 370, 392, 400, 430, 470, 700, bai, broadcast, cc, e7f, ehp, f37, f43, f47, general, hc, heb, hep, hmu, hwc, mc, mc.3, mc.4, mc.5, mc.6, mc.7, omu, omu.1, pms, rcc, rcc.1, rcc.3, rcc.4, rcc.5, rcc.6, rcc.7, sc, scan, sdr_p, ui, uih, v65, v81, v81.1, v81.3, v81.4, v81.5, v81.6, v81.7, vd2, vd3, vd4, vd6, vl8, vl9, vr_70, vr_71, zeo
Hmmm, jetzt habe ich etwas "gehirnt", komme aber nicht so recht weiter:
Ausgangspunkt war mal:
attr DEVICE bridgeRegexp (ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"\
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"\
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"Die erste Zeile würde damit wie folgt aussehen:
attr DEVICE bridgeRegexp (ebus.)[^/]*/(bai|broadcast|cc|e7f|ehp|f[\d][\d]|general|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|scan|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\ABER: Was mache ich mit der dritten? Die hat bisher die "(bai|broadcast)"-Messages quasi als Gegenstück "durchgelassen".
Nach wie vor sind meine regex-Kenntnisse "verbesserungsfähig", vielleicht hat ja jemand eine Idee. Ich sehe zwei Ansatzpunkte:
Entweder ich erweitere die Zeile 3 "irgendwie" (?) mit "(*FAIL)"-Anweisungen, oder (was mir besser gefallen würde), die Frage nach $2 wird bereits in der ersten Zeile optional, und wenn vorhanden, dann "$1_$2" verwendet, sonst nur "$1".
Könnte im ERgebnis dann so aussehen:
attr DEVICE bridgeRegexp (ebus.)[^/]*/(bai|broadcast|cc|e7f|ehp|f[\d][\d]|general|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|scan|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)?/.*:.* $2?"$1_$2":"$1"\
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"@Rudi: Könnte das "hinten" überhaupt so klappen? (Ansonsten wäre etwas Nachhilfe in regex wg. der 3. Zeile nett...)
@Reinhart: könnte ich das gefahrlos testen?
Oder gibt es sonst jemand, der einfach mal gefahrlos ausprobieren kann, ob das funktioniert?
ja natürlich kannst du das gefahrlos testen!
Irgendwie verstehe ich aber nicht warum du die Geräte alle nach $1_bai schieben willst. Die "bai" ist ja schon ein Gerät. Die Calormatic 430 wird ja durch die 2. Regexp auch schön brav als $1_430 angelegt, das klappt doch prima. Ich finde es sogar übersichtlicher wenn jedes Gerät am eBus als eigenes Device angelegt wird sonst werden die Readings pro Device sehr unübersichtlich, also besser so lassen wie es jetzt ist.
Die Template sind ja so aufgebaut, das sie meist nur innerhalb eines Devices funktionieren weil dort eben gewisse Readings vorhanden sind die nur für dieses Device zutreffen. ZB: "hcurve" gibt es nur bei Zusatzgeräten wie Calormatic oder ähnlichem, also 700, 430,470, 470f, 350 und so weiter, aber nie in einer "bai" weil das eben nur das Grundgerät ist und in dieser Ausstattung noch keine Heizkurve kennt.
LG
Zitat von: Reinhart am 02 April 2019, 15:02:06
ja natürlich kannst du das gefahrlos testen!
Um es auszutesten, würde ich aber alle vorhandenen ebus-MQTT2-Devices (mehrfach) löschen müssen und zwischendurch speichern... Das wollte ich dann nicht so nebenbei ohne Ankündigung machen, nachdem ich den Zugang seit längerem nicht mehr "zerstörend" genutzt hatte.
ZitatIrgendwie verstehe ich aber nicht warum du die Geräte alle nach $1_bai [...]
Sorry, Mißverständnis, das will ich gar nicht, im Gegenteil: auch bai und broadcast bekommen dann eigene Geräte, so dass braodcast nicht weiter in "bai" landet, obwohl jemand ein ehp nutzt und mit "bai" nichts anfangen kann ;) .
Die Logik soll sein (unabhängig von der Aufteilung in die einzelnen Zeilen): Alles, was separat aufgelistet ist, bekommt $1_$2 (wenn $2 dann z.B. broadcast oder bai oder ehp ist), nur was zwar $1 hat, aber nicht in der Liste auftaucht ($2 undef), kommt zu "ebusd" (=idR. $1 "solo").
@Reinhart
Das Template läuft soweit
Ein kleiner Fehler hat sich dennoch eingeschlichen.
Bei mir werden 2 Werte nicht richtig gesetzt.
bei Wednesday fehlte ein 3
Dein Code:fhem "set ebusMQTT publish ebusd/BASE_DEV/hcTimer.Wednesday/set " . ReadingsVal("TimeMi","HHMM1w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM2w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMMw",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM4w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM5w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM6w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM7w",0);;\
richtiger Code:
fhem "set ebusMQTT publish ebusd/BASE_DEV/hcTimer.Wednesday/set " . ReadingsVal("TimeMi","HHMM1w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM2w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM3w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM4w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM5w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM6w",0) . chr(59) . chr(59) . ReadingsVal("TimeMi","HHMM7w",0);;\
und du hast 2x "Thuesday" anstatt "tuesday" und "thursday"
Danke fürs testen und für die Korrektur.
LG
So, erst mal wieder ein aktualisierter Vorschlag zur bridgeRegexp am "splitter":
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|broadcast|[\d]+|cc|e7f|ehp|f[\d][\d]|general|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|scan|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global)/.*:.* "$1"
Leider wollte das mit der Unterscheidung ob $2 jetzt vorhanden ist oder nicht nicht so recht, aber so müßte es jetzt eigentlich im Großen und Ganzen passen.
Anmerkungen:
- Das ist nur im laufenden Betrieb getestet, also ohne den ebusd neu zu starten; ob das sauber sortiert wird, was da ggf. noch am messages kommt, kann ich daher nicht abschließend sagen.
- Hart auf das Gerät mit der "ebusd"-CID umgeleitet habe ich jetzt die global-Messages, die scheinen sich wirklich auf den ebusd-Dämon zu beziehen. Im Moment würde ich dazu neigen, auf dieses Gerät auch "general" und "scan" umzuleiten (das also von der ersten in die 2. Zeile zu verschieben), diese sind nach John30 Auskunft ja auch "rein intern".
- Wenn ich es richtig verstanden habe, ist broadcast auch eher so ein allgemeines topic und kein wirkliches Gerät, aber dafür auch auf allen ebus-Systemen vorhanden (vermutlich mit gleichem Inhalt?). Würde es da nicht Sinn machen, auch diese Readings noch im ebus-MQTT2-Gerät zu sammeln?
Ergäbe dann ins Unreine:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"
Wäre schön, wenn ihr Rückmeldung dazu geben könntet, dann würde ich das baldmöglichst einpflegen.
(Und ein JSONMAP-template für "bai" (ehp wäre gleich?) wäre auch noch nett...)
Ich habe jetzt den Dämon neu gestartet und auch das Log mit den Fehlermeldungen angesehen, aber da dürfte noch was nicht so stimmen.
2019.04.03 19:09:05 5: PUBLISH: 0(25)(0)(19)ebusd/global/uptime5446
2019.04.03 19:09:05 4: ebusMQTT_10.0.0.8_42278 ebusd_3.2_3783 PUBLISH ebusd/global/uptime:5446
2019.04.03 19:09:05 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.2_3783\000ebusd/global/uptime\0005446
2019.04.03 19:09:06 5: PUBLISH: 0(145)(1)(0)(18)ebusd/bai/DateTime{ "dcfstate": {"value": "nosignal"}, "btime": {"value": "03:19:06"}, "bdate": {"value": "-.-.-"}, "temp2": {"value": 14.312}}
2019.04.03 19:09:06 4: ebusMQTT_10.0.0.8_42278 ebusd_3.2_3783 PUBLISH ebusd/bai/DateTime:{ "dcfstate": {"value": "nosignal"}, "btime": {"value": "03:19:06"}, "bdate": {"value": "-.-.-"}, "temp2": {"value": 14.312}}
2019.04.03 19:09:06 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.2_3783\000ebusd/bai/DateTime\000{ "dcfstate": {"value": "nosignal"}, "btime": {"value": "03:19:06"}, "bdate": {"value": "-.-.-"}, "temp2": {"value": 14.312}}
2019.04.03 19:09:06 1: PERL WARNING: Backslash found where operator expected at (eval 6694) line 1, near ""$1_$2"\"
2019.04.03 19:09:06 1: PERL WARNING: Scalar found where operator expected at (eval 6694) line 1, near "* "$1"
2019.04.03 19:09:06 1: PERL WARNING: String found where operator expected at (eval 6694) line 1, at end of line
2019.04.03 19:09:06 1: MQTT2_DEVICE: Error evaluating "$1_$2"\ (ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1": Can't find string terminator '"' anywhere before EOF at (eval 6694) line 1.
Ich habe nun alle angelegten Devices gelöscht. die Regexp installiert und autocreate wieder auf 1 gestellt (MQTT2_ebusd). Die Fehlermeldung ist nun weg (habe die regExp vom Post verwendet), aber autrocreate legt nun in "MQTT2_ebusd_3.2_378" an. Einige Devices werden überhaupt nicht mehr angelegt (430).
Ich teste jetzt noch weiter um dahinter zu kommen was da schief läuft.
LG
Ok, Fehler gefunden, da war ich schuld weil ich einfach die regExp aus deinem Post kopiert habe und hier ein "\" vorhanden ist. Beim Fhem internen Editor entfällt der natürlich!
LG
Sorry, hätte ich auch deutlicher schreiben können...
Btw.: was mir bei manchen templates aufgefallen ist, die ich testweise zum teil aufgerufen habe: Da steckt manchmal gar keine ReadingList dahinter. Dadurch erhält man zwar eine Anzeige, die den beim Aufruf der Seite aktuellen Stand wiedergibt, aber aktualisiert wird dann nichts. Das geschieht bei Perl-devStateIcon-Code nur, wenn sich ein Reading ändert (eventuell sogar nur dann, wenn das betr. Reading im Code abgefragt wird).
Dass der Code an sich funktioniert ist klar (das hatte ich ja soweit auf demselben System getestet), offen waren
- das Verhalten, wenn der ebusd neu gestartet wird bzw. sonst irgendwie dazu veranlaßt, neue Info zu senden (die scan-Messages würden mich speziell interessieren, die waren teilweise "besonders", die finde ich grade auf dem Testsystem aber nicht in irggendeinen Device, oder?), und
- die Zuordnung der genannten topic-Pfade in einzelne Geräte oder das ebusd-Gerät selbst.
Wäre nett, wenn dazu jemand was sagen könnte (gut wäre, wenn es auch mit MQTT2_CLIENT jemand testen könnte; sollte zwar keine Probleme geben, aber leider erleben wir ja alle gelegentlich Dinge, die sich erst nach intensiverem Nachdenken erklären lassen :) ).
also das mit der readingList ist ja so, das im "MQTT2_ebusd_bai" die readingList ja automatisch angelegt wird und der anzuzeigende neue Device ja mit ReadingsVal auf dieses Reading zugreift. Ändert sich das betreffende Reading im "bai", dann ist das ja auch eine Änderung im Zieldevice.
"{my $vD = ReadingsVal("MQTT2_ebusd_bai", "WaterPressure_press_value", "30"); 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>"}"
Ich habe das jetzt verglichen mit ECMD Daten und das passt soweit. Bei der Pumpe und dem Ventilator fällt das besser auf, weil die sich öfters ändern und das wird online sofort aktualisiert.
Den MQTT2_CLIENT teste ich im Hauptsystem und gebe dann morgen bescheid. Den eBus hatte ich am Testsystem schon gestern gestartet, habe es aber jetzt auch nochmals durchgeführt. Es kommen ja dann diese "MQTT2_ebusd_3.2_5143" Meldungen mit der Versionsnummer vom Scan. Die werden angelegt und der Inhalt passt auch.
Internals:
CFGFN
CID ebusd_3.2_5143
DEF ebusd_3.2_5143
DEVICETOPIC MQTT2_ebusd_3.2_5143
FUUID 5ca6237f-f33f-f7ac-890e-00329ef74dfa1f60
IODev ebusMQTT
NAME MQTT2_ebusd_3.2_5143
NR 531
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-04-04 17:32:15 scan.08_HW_value 7401
2019-04-04 17:32:15 scan.08_ID_value BAI00
2019-04-04 17:32:15 scan.08_MF_value Vaillant
2019-04-04 17:32:15 scan.08_SW_value 0518
2019-04-04 17:32:18 scan.15_HW_value 2002
2019-04-04 17:32:18 scan.15_ID_value 43000
2019-04-04 17:32:18 scan.15_MF_value Vaillant
2019-04-04 17:32:18 scan.15_SW_value 0215
Attributes:
IODev ebusMQTT
readingList ebusd_3.2_5143:ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd_3.2_5143:ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }
room MQTT2_DEVICE
LG
**Grummel*** sowas hatte ich befürchtet.
Die bisherige bridgeRegexp mag die scan-Geschichten nicht, alles kommt in das via CID identifizierte Device. Das hier sollte für Abhilfe sorgen, und für jeden .nn-Scan ein eigenes Device anlegen:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|broadcast|[\d]+|cc|e7f|ehp|f[\d][\d]|general|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|scan[^/]*|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global)/.*:.* "$1"
EDIT:
Wie wäre es, auch die scan-Infos in das ebusd-Gerät umzuleiten?
da hat sich jetzt aber nichts geändert.
Internals:
CFGFN
CID ebusd_3.2_6203
DEF ebusd_3.2_6203
DEVICETOPIC MQTT2_ebusd_3.2_6203
FUUID 5ca6f2f7-f33f-f7ac-6fdf-f5093fcfe46cddd1
IODev ebusMQTT
NAME MQTT2_ebusd_3.2_6203
NR 657
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-04-05 08:17:27 outsidetemp_temp2_value 4.875
2019-04-05 08:17:27 scan.08_HW_value 7401
2019-04-05 08:17:27 scan.08_ID_value BAI00
2019-04-05 08:17:27 scan.08_MF_value Vaillant
2019-04-05 08:17:27 scan.08_SW_value 0518
Attributes:
IODev ebusMQTT
readingList ebusd_3.2_6203:ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }
ebusd_3.2_6203:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }
room MQTT2_DEVICE
Mich stört das nicht wenn die Scan Infos in ein eigenes Device wandern, so bleibt die Übersicht besser als wenn alles in einem Device liegt. Bei den Templates mache ich es ja auch so, dass ich eigene Devices generiere nur der Übersicht halber.
Ebenfalls habe ich mir jetzt den im Hauptsystem den MQTT2_CLIENT angesehen und auch dort funktioniert alles. Dazu ist meine Umgebung mit den 2 Geräten aber etwas einseitig, dass müsste ein User mit vielen Geräten einmal austesten. Eigentlich sehe ich ja bei meiner Konstellation keinen Unterschied zur vorherigen bridgeRegexp. Interessant wären ja auch Umgebungen mit Solareinspeisung, da gäbe es dann auch genug Rohdaten für weitere Templates kann ich mir vorstellen.
Was passiert eigentlich Fhem intern mit so komplexen Regexp? Ist das nicht ein Einfluß auf die Gesamtperformance, denn das Filter muss ja erst abgearbeitet werden. Ich habe mit dem ganzen MQTT2 Zeugs jetzt jede Menge DbLogExclude eingebaut, weil sonst die Db die Gui so langsam macht. Kritisch sind hier vor allem die readingsgroup weil die ja auch meist Temperaturen enthalten (die ohnehin schon abgelegt sind) die alle paar Sekunden eintreffen. Der automatischen Pflege der Datenbank ( reduceLog und deleteOldDays ) ist hier ein besonderes Augenmerk zu widmen.
LG
Zitat von: Reinhart am 05 April 2019, 08:56:41
da hat sich jetzt aber nichts geändert.
Leider doch: Es landen jetzt auch die Broadcast-Infos im "Sammeldevice" rein auf CID-Basis (ebusd_3.2_6203) (EDIT: Fehler gefunden, da das nachfolgende aber schon geschrieben war und ggf. zum Verständnis wichtig ist); die CID ist zu allem Überfluß beim ebusd scheinbar auch noch volatil. Zur Klarstellung: Du scheinst davon auszugehen, dass das nur ein unwichtiger Nebenaspekt ist, aber m.E. ist das eine Symptomatik, hinter der ein echtes Problem steht, das nur nicht erkennbar ist, weil die Zahl der Geräte zu gering ist. Du brauchst nur mal nachzusehen, wieviele und welche FileLog-Devices mit definiert wurden, dann ahnst du vielleicht, was ich meine.
Und dass der broadcast-Filter jetzt nicht mehr greift, ist auch "gar nicht gut"...
@John30: könnte man dem ebusd das abgewöhnen und in der config irgendwo optional eine CID festlegen? (Das hilft allerdings nicht, wenn MQTT2_CLIENT eingesetzt wird, ist also keine Lösung, sondern nur eine Verbesserung...).
ZitatMich stört das nicht wenn die Scan Infos in ein eigenes Device wandern, so bleibt die Übersicht besser als wenn alles in einem Device liegt. Bei den Templates mache ich es ja auch so, dass ich eigene Devices generiere nur der Übersicht halber.
Meine Meinung: Es sollte zwar alles in ein eigenes Device, was wirklich separates "Gerät" (auch im Hardware-Sinn) ist. Ob aber die "Atomisierung" aller Informationen Sinn macht, erscheint mir nicht so ganz zwingend, vor allem dann nicht, wenn diese Art Daten tatsächlich auf (fast) allen Systemen vorhanden sind und im Prinzip statisch (sind die scan-Infos doch im wesentlichen, oder?). Dann hat man alle Infos "an einem Ort" und kann dann ggf. selbst in STATE packen, was man da haben möchte (macht m.E. bei dieser Art Info nicht den großen Sinn).
Unabhängig von allem, müssen wir erst mal funktionierende Teil-Abfragen haben und können dann immer noch entscheiden, wie es effektiv weitergehen soll. Ich würde jetzt mal mit folgendem an den Start gehen:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
Grade zu den Geräten ohne ReadingList: werden die aktualisiert, wenn du das betreffende Browserfenster einfach offen hältst? (Ich habe sowas ähnliches mit meinen HM-RTs/WTs realisiert, und da werden "externe Daten" (von anderen Kanälen als dem dargestellten) nur dann aktualisiert, wenn sich ein "echtes" Reading des Devices ändert.) Ansonsten muß man die Seite neu laden...
Zur Belastung mit der bridgeRegexp: Die wird nach meinem Verständnis ja erst aufgerufen, wenn zwei Bedingungen zutreffen:
1. muß autocreate aktiv sein und (v.a.)
2. darf es nicht schon ein readingList-Elemet geben, das "die Info fängt".
Gerade wegen 2. sehe ich den Impact als gering an, aber Rudi wird mir da bestimmt widersprechen, wenn ich das falsch verstanden haben sollte.
Die Belastung sehe ich auch nicht.
Wenn aber so ein Regexp noetig ist, dann macht man was falsch, oder die Architektur (meine Baustelle) ist daneben, da man das nicht sinnvoll warten kann.
Gibt es nicht was Anderes, an dem man solche Topics einfach erkennen kann?
Wenn nicht: kann man nicht mit den ebus Leuten reden, dass sie das einbauen?
Evtl. hilft auch eine Vereinfachung, was zwar theoretisch nicht alle zukuenftigen Faelle abfaengt, aber verstaendlich bleibt.
Uebrigens:
- [\d] ist equivalent mit \d
- (ebus.*)[^/]*/ kann man auch als (ebus.*?)/ schreiben
- v[\d][\d] deckt v81 ab.
ZitatIch habe mit dem ganzen MQTT2 Zeugs jetzt jede Menge DbLogExclude eingebaut, weil sonst die Db die Gui so langsam macht. Kritisch sind hier vor allem die readingsgroup weil die ja auch meist Temperaturen enthalten (die ohnehin schon abgelegt sind) die alle paar Sekunden eintreffen.
Man kann unerwuenschte Readings mit jsonMap unterdruecken, oder per event-min-interval filtern.
Allerdings waere sowas am besten auch im ebus2mqtt gefiltert: je frueher, desto besser.
Zitat von: rudolfkoenig am 05 April 2019, 10:27:12
Man kann unerwuenschte Readings mit jsonMap unterdruecken
Kommt mir wie eine neue Info vor. Ohne jetzt die Doku nochmal gegengeprüft zu haben: Wo findet man dazu eine Erklärung/ein Beispiel? Das wäre eventuell in der Tat ein Argument für "complex" bei manchen eigentlich einfachen Geräten.
Zitat von: rudolfkoenig am 05 April 2019, 10:15:37
Evtl. hilft auch eine Vereinfachung, was zwar theoretisch nicht alle zukuenftigen Faelle abfaengt, aber verstaendlich bleibt.
Na ja, da das via template kommt, kann es m.E. auch kompliziert sein und braucht nicht unbedingt durch den User verstanden zu werden. Allerdings ist die Topic-Struktur insgesamt schon eine Sache, die eventuell zu überdenken wäre (@Rudi: John30 liest hier ja mit, du "redest" also bereits mit ihm...). Aber wenn das Konzept eben so ist, dass der ebusd eben eine Art bridge für die am Bus angeschlossenen Geräte ist, und die so unterschiedlich sein können, ist es eben, wie es ist... Man sollte nur zusammenfassen, was inhaltlich zusammen gehört. (In diese Richtung gingen ja meine wiederholten Fragen, ob es nicht sinnvoll wäre, manche Dinge zusammenzufassen).
ZitatUebrigens:
- [\d] ist equivalent mit \d
- (ebus.*)[^/]*/ kann man auch als (ebus.*?)/ schreiben
- v[\d][\d] deckt v81 ab.
Danke für die Hinweise, ich bin auch erst am lernen und kopiere (zu?) oft einfach Sachen, die ich woanders gesehen habe.
"(ebus.)[^/]*/" sollte so bleiben, da (ggf. auch erst über einen Umweg) gelegentlich auch sehr schräge "vorneweg"-Angaben, beginnend mit "ebusd" gebildet wurden. "ebusd" wird am Dämon konfiguriert und ist Quasi-Standard. Da es möglich ist, dass jemand mehrere ebus-Dämonen betreibt, wäre dann eben der nächste mit "ebuse" oder "ebusf" zu konfigurieren, da kommt der eine Punkt her...
Bereinigte Fassung:
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus.)[^/]*/(global|broadcast|general|scan([^/]*))/.*:.* "$1"Ist am Testsystem eingerichtet, scheint (bis auf das von mir nicht testbare scan!) zu funktionieren.
ZitatWo findet man dazu eine Erklärung/ein Beispiel?
https://fhem.de/commandref_modular.html#jsonMap
ZitatDa es möglich ist, dass jemand mehrere ebus-Dämonen betreibt, wäre dann eben der nächste mit "ebuse" oder "ebusf" zu konfigurieren, da kommt der eine Punkt her.
Ok, dann halt (ebus..*?)/, immer noch kuerzer/einfacher lesbar.
Meine Loesung waere: wer mehr als ein ebus Daemon hat (meine Annahme: das ist selten), der soll den Regexp anpassen. Dafuer ist der Normalfall verstaendlich.
Zitat von: rudolfkoenig am 05 April 2019, 11:16:04
https://fhem.de/commandref_modular.html#jsonMap (https://fhem.de/commandref_modular.html#jsonMap)
...hätte ich mir eigentlich denken können...
Da wir grade bei commandref-Themen sind: Ich habe in https://fhem.de/commandref_modular.html#MYSENSORS_DEVICE mal einen englischen Text zu attrTemplate reingebaut. Wenn der paßt, könnte man das gerne nach MQTT2_DEVICE entsprechend übertragen; ich kann gerne auch eine deutsche Übersetzung liefern. (Was immer nicht so spaßig ist: den richtigen "level" bei der commandref-Sprache zu treffen, daher nur "notfalls" das Angebot, auch einen patch zu liefern)
ZitatOk, dann halt (ebus..*?)/, immer noch kuerzer/einfacher lesbar.
So wird's gemacht.
attr MQTT2_ebusd bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
ZitatMeine Loesung waere: wer mehr als ein ebus Daemon hat (meine Annahme: das ist selten), der soll den Regexp anpassen. Dafuer ist der Normalfall verstaendlich.
In dem Zusammenhang: irgendwie hatte ich den Eindruck, dass die seltsamen topic-Pfade, die durch den weiteren ".?" abgefangen werden sollen, auch daher kamen, dass irgendwas im Kreis ging; leider kann ich das nicht konkreter beschreiben, aber es kam vermutlich entweder von dem Punkt im Topic-Pfad, den die scans erzeugen, oder es hatte was damit zu tun, dass auf dem Testsystem in der Ausgangskonfiguration mal ein CLIENT auf einen 2-er-SERVER gehört hatte (das habe ich leider erst später gemerkt).
Wenn das grundsätzlich ausgeschlossen werden kann und nur was mit dem Testsystem zu tun hat: Gerne.
(Das letzte war eigentlich eine Frage @all).
@Rudi ergänzend noch:
Ich betreibe mein Testsystem auch mit CLIENT und höre damit den SERVER auf dem Hauptsystem ab, damit ich Testdevices habe. Führt halt bei beiderseits eingeschaltetem Autocreate dazu, dass dass Hauptsystem wieder auf dem Hauptsystem als Abbild der vom Testsytem her ausgeführten MQTT-Anweisungen angelegt wird; wenn da escapte Sonderzeichen im Topic-Pfad drin sind, gibt das seltsame Ping-Pong-Spiele. Bei Gelegenheit scheibe ich mal was dazu, das ist hier OT, und ich habe dazu auch zu wenig konkretes bzw. selbst gehirnt...
Aber vielleicht kannst du das aus eigener Anschauung auch so verstehen, daher an der Stelle die Bemerkung; ansonsten: Vorerst wieder vergessen ;) .
Zitat von: Beta-User am 05 April 2019, 09:39:07
Grade zu den Geräten ohne ReadingList: werden die aktualisiert, wenn du das betreffende Browserfenster einfach offen hältst? (Ich habe sowas ähnliches mit meinen HM-RTs/WTs realisiert, und da werden "externe Daten" (von anderen Kanälen als dem dargestellten) nur dann aktualisiert, wenn sich ein "echtes" Reading des Devices ändert.) Ansonsten muß man die Seite neu laden...
Ja, das funktioniert. Man kann das leicht nachstellen, in einem Browserfenster öffnet man die Ansicht Pumpe mit Ventilator, im 2. Browserfenster erhöhe ich die Heizkurve und nach kurzer Zeit läuft die Pumpe und der Ventilator ( live ) hoch ohne einen Refresh im Browser durchzuführen zu müssen. Getestet mit Chrome Browser. Gleiches gilt wenn ich vom Hauptsystem über ECMD Kommandos losschicke (geht ja auf denselben eBus ), die sind im Testsystem bei offenem Fenster ebenfalls sofort sichtbar. In beiden Fällen, wird ja auch das "echte" Reading geändert. Das "sofort" bezieht sich allerdings nach dem zyklischen Eintreffen der MQTT Strings.
LG
/list topic ist eingebaut, siehe wiki (https://github.com/john30/ebusd/wiki/3.3.-MQTT-client)
Zitat von: john30 am 07 April 2019, 21:09:08
/list topic ist eingebaut, siehe wiki (https://github.com/john30/ebusd/wiki/3.3.-MQTT-client)
Thx.
Aktualisiertes template für den ebus-Dämon an sich ging eben ins svn (ein noArg füge ich bei Gelegenheit dazu, das ist mir eben auf die Schnelle durchgerutscht). Hoffe, das im Wiki richtig interpretiert zu haben, dass eine Payload an sich sinnvoll ist; bitte um Rückmeldung, wenn jemand da Verbesserungsbedarf sieht.
attr DEVICE setList getKnown DEV_ID/global/list onlyknownDa die Online- und Signal-Messages einen last will haben, gibt's dafür jetzt auch Symbole, allerdings wäre ich da auch für "hübschere" Varianten offen, habe halt erst mal genommen, was auf die Schnelle verfügbar war.
global|broadcast|general|scan habe ich jetzt mal dem ebusd-Gerät zugeordnet, da sich bisher keiner mit einer besseren Idee gemeldet hat...
@Reinhart:
Wäre schön, wenn du bei Gelegenheit den ebusd-Dienst auf dem Testsystem auf die letzte Version heben könntest :) .
Danke John, funktioniert!
Ich habe die letzte Version compiliert, beim "bushandler.o" erhalte ich eine Warning:
CXX device.o
CXX message.o
AR libebus.a
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Verzeichnis ,,/home/pi/ebusd/src/lib/ebus" wird verlassen
make[2]: Verzeichnis ,,/home/pi/ebusd/src/lib/ebus" wird verlassen
Making all in src/ebusd
make[2]: Verzeichnis ,,/home/pi/ebusd/src/ebusd" wird betreten
CXX bushandler.o
bushandler.cpp: In member function 'void ebusd::BusHandler::formatGrabResult(bool, bool, std::ostringstream*, bool, time_t, time_t) const':
bushandler.cpp:1561:19: warning: suggest parentheses around '&&' within '||' [-W parentheses]
if (since > 0 && it.second.getLastTime() < since
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CXX datahandler.o
CXX network.o
CXX mainloop.o
Wenn ich nun Abfrage erhalte ich mit:
set ebusMQTT publish ebusd/bai/list
folgende Liste
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/list', ... (0 bytes))
ebusd/bai/list (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AATemp', ... (0 bytes))
ebusd/bai/AATemp (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AccessoriesOne', ... (0 bytes))
ebusd/bai/AccessoriesOne (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AccessoriesOne', ... (0 bytes))
ebusd/bai/AccessoriesOne (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AccessoriesTwo', ... (0 bytes))
ebusd/bai/AccessoriesTwo (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AccessoriesTwo', ... (0 bytes))
ebusd/bai/AccessoriesTwo (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ACRoomthermostat', ... (0 bytes))
ebusd/bai/ACRoomthermostat (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AircontrolOk', ... (0 bytes))
ebusd/bai/AircontrolOk (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AITemp', ... (0 bytes))
ebusd/bai/AITemp (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AntiCondensValue', ... (0 bytes))
ebusd/bai/AntiCondensValue (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/AntiCondensValue', ... (0 bytes))
ebusd/bai/AntiCondensValue (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/averageIgnitiontime', ... (0 bytes))
ebusd/bai/averageIgnitiontime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/BlockTimeHcMax', ... (0 bytes))
ebusd/bai/BlockTimeHcMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/BlockTimeHcMax', ... (0 bytes))
ebusd/bai/BlockTimeHcMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/BoilerType2', ... (0 bytes))
ebusd/bai/BoilerType2 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/BoilerType', ... (0 bytes))
ebusd/bai/BoilerType (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ChangesDSN', ... (0 bytes))
ebusd/bai/ChangesDSN (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/CirPump', ... (0 bytes))
ebusd/bai/CirPump (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/clearerrorhistory', ... (0 bytes))
ebusd/bai/clearerrorhistory (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/CounterStartattempts1', ... (0 bytes))
ebusd/bai/CounterStartattempts1 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/CounterStartattempts2', ... (0 bytes))
ebusd/bai/CounterStartattempts2 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/CounterStartAttempts3', ... (0 bytes))
ebusd/bai/CounterStartAttempts3 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/currenterror', ... (0 bytes))
ebusd/bai/currenterror (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DateTime', ... (145 bytes))
ebusd/bai/DateTime {
"dcfstate": {"value": "nosignal"},
"btime": {"value": "06:33:39"},
"bdate": {"value": "-.-.-"},
"temp2": {"value": 12.250}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/dcfState', ... (0 bytes))
ebusd/bai/dcfState (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DCFTimeDate', ... (0 bytes))
ebusd/bai/DCFTimeDate (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DCRoomthermostat', ... (0 bytes))
ebusd/bai/DCRoomthermostat (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DeactivationsIFC', ... (0 bytes))
ebusd/bai/DeactivationsIFC (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DeactivationsTemplimiter', ... (0 bytes))
ebusd/bai/DeactivationsTemplimiter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DeltaFlowReturnMax', ... (0 bytes))
ebusd/bai/DeltaFlowReturnMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DisplayMode', ... (0 bytes))
ebusd/bai/DisplayMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DSN', ... (0 bytes))
ebusd/bai/DSN (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DSNOffset', ... (0 bytes))
ebusd/bai/DSNOffset (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DSNOffset', ... (0 bytes))
ebusd/bai/DSNOffset (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DSNStart', ... (0 bytes))
ebusd/bai/DSNStart (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/EBusHeatcontrol', ... (0 bytes))
ebusd/bai/EBusHeatcontrol (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/EbusSourceOn', ... (0 bytes))
ebusd/bai/EbusSourceOn (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/EbusVoltage', ... (0 bytes))
ebusd/bai/EbusVoltage (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/errorhistory', ... (0 bytes))
ebusd/bai/errorhistory (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ExhaustCurve', ... (0 bytes))
ebusd/bai/ExhaustCurve (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ExhaustCurve', ... (0 bytes))
ebusd/bai/ExhaustCurve (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/exhaustWayBlockCounter', ... (0 bytes))
ebusd/bai/exhaustWayBlockCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/expertlevel_ReturnTemp', ... (0 bytes))
ebusd/bai/expertlevel_ReturnTemp (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ExternalFaultmessage', ... (0 bytes))
ebusd/bai/ExternalFaultmessage (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/externalFlowTempDesired', ... (0 bytes))
ebusd/bai/externalFlowTempDesired (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/externalHwcSwitch', ... (0 bytes))
ebusd/bai/externalHwcSwitch (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ExternGasvalve', ... (0 bytes))
ebusd/bai/ExternGasvalve (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ExtFlowTempDesiredMin', ... (0 bytes))
ebusd/bai/ExtFlowTempDesiredMin (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/extWP', ... (0 bytes))
ebusd/bai/extWP (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanHours', ... (0 bytes))
ebusd/bai/FanHours (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanMaxSpeedOperation', ... (0 bytes))
ebusd/bai/FanMaxSpeedOperation (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanMinSpeedOperation', ... (0 bytes))
ebusd/bai/FanMinSpeedOperation (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanPWMSum', ... (0 bytes))
ebusd/bai/FanPWMSum (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanPWMTest', ... (0 bytes))
ebusd/bai/FanPWMTest (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanSpeed', ... (37 bytes))
ebusd/bai/FanSpeed {
"0": {"name": "", "value": 0}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanStarts', ... (0 bytes))
ebusd/bai/FanStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Flame', ... (0 bytes))
ebusd/bai/Flame (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlameSensingASIC', ... (0 bytes))
ebusd/bai/FlameSensingASIC (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FloorHeatingContact', ... (0 bytes))
ebusd/bai/FloorHeatingContact (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowsetHcMax', ... (0 bytes))
ebusd/bai/FlowsetHcMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowsetHcMax', ... (0 bytes))
ebusd/bai/FlowsetHcMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowsetHwcMax', ... (0 bytes))
ebusd/bai/FlowsetHwcMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowsetHwcMax', ... (0 bytes))
ebusd/bai/FlowsetHwcMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowSetPotmeter', ... (0 bytes))
ebusd/bai/FlowSetPotmeter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowTemp', ... (64 bytes))
ebusd/bai/FlowTemp {
"temp": {"value": 30.44},
"sensor": {"value": "ok"}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowTempDesired', ... (32 bytes))
ebusd/bai/FlowTempDesired {
"temp": {"value": 36.50}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Fluegasvalve', ... (0 bytes))
ebusd/bai/Fluegasvalve (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Gasvalve3UC', ... (0 bytes))
ebusd/bai/Gasvalve3UC (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Gasvalve', ... (0 bytes))
ebusd/bai/Gasvalve (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GasvalveASICFeedback', ... (0 bytes))
ebusd/bai/GasvalveASICFeedback (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GasvalveUC', ... (0 bytes))
ebusd/bai/GasvalveUC (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GasvalveUCFeedback', ... (0 bytes))
ebusd/bai/GasvalveUCFeedback (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GVStepOffsetMax', ... (0 bytes))
ebusd/bai/GVStepOffsetMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GVStepOffsetMax', ... (0 bytes))
ebusd/bai/GVStepOffsetMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GVStepOffsetMin', ... (0 bytes))
ebusd/bai/GVStepOffsetMin (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/GVStepOffsetMin', ... (0 bytes))
ebusd/bai/GVStepOffsetMin (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcHours', ... (0 bytes))
ebusd/bai/HcHours (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcPumpMode', ... (0 bytes))
ebusd/bai/HcPumpMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcPumpMode', ... (0 bytes))
ebusd/bai/HcPumpMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcPumpStarts', ... (0 bytes))
ebusd/bai/HcPumpStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcStarts', ... (0 bytes))
ebusd/bai/HcStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcUnderHundredStarts', ... (0 bytes))
ebusd/bai/HcUnderHundredStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HeatingSwitch', ... (0 bytes))
ebusd/bai/HeatingSwitch (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HoursTillService', ... (0 bytes))
ebusd/bai/HoursTillService (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HoursTillService', ... (0 bytes))
ebusd/bai/HoursTillService (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcDemand', ... (0 bytes))
ebusd/bai/HwcDemand (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcHours', ... (0 bytes))
ebusd/bai/HwcHours (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcImpellorSwitch', ... (0 bytes))
ebusd/bai/HwcImpellorSwitch (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcPostrunTime', ... (0 bytes))
ebusd/bai/HwcPostrunTime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcPostrunTime', ... (0 bytes))
ebusd/bai/HwcPostrunTime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcSetPotmeter', ... (0 bytes))
ebusd/bai/HwcSetPotmeter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcStarts', ... (0 bytes))
ebusd/bai/HwcStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcSwitch', ... (0 bytes))
ebusd/bai/HwcSwitch (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcTemp', ... (0 bytes))
ebusd/bai/HwcTemp (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcTempDesired', ... (0 bytes))
ebusd/bai/HwcTempDesired (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcTempMax', ... (0 bytes))
ebusd/bai/HwcTempMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcTempMax', ... (0 bytes))
ebusd/bai/HwcTempMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcTypes', ... (0 bytes))
ebusd/bai/HwcTypes (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcUnderHundredStarts', ... (0 bytes))
ebusd/bai/HwcUnderHundredStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcWaterflow', ... (0 bytes))
ebusd/bai/HwcWaterflow (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcWaterflowMax', ... (0 bytes))
ebusd/bai/HwcWaterflowMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Ignitor', ... (0 bytes))
ebusd/bai/Ignitor (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/IonisationVoltageLevel', ... (0 bytes))
ebusd/bai/IonisationVoltageLevel (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/maintenancedata_HwcTempMax', ... (0 bytes))
ebusd/bai/maintenancedata_HwcTempMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/maxIgnitiontime', ... (0 bytes))
ebusd/bai/maxIgnitiontime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/minIgnitiontime', ... (0 bytes))
ebusd/bai/minIgnitiontime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ModulationTempDesired', ... (0 bytes))
ebusd/bai/ModulationTempDesired (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/OutdoorstempSensor', ... (64 bytes))
ebusd/bai/OutdoorstempSensor {
"temp": {"value": 12.50},
"sensor": {"value": "ok"}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/OverflowCounter', ... (0 bytes))
ebusd/bai/OverflowCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ParamToken', ... (0 bytes))
ebusd/bai/ParamToken (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PartloadHcKW', ... (0 bytes))
ebusd/bai/PartloadHcKW (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PartloadHcKW', ... (0 bytes))
ebusd/bai/PartloadHcKW (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PartloadHwcKW', ... (0 bytes))
ebusd/bai/PartloadHwcKW (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PartloadHwcKW', ... (0 bytes))
ebusd/bai/PartloadHwcKW (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PartnumberBox', ... (0 bytes))
ebusd/bai/PartnumberBox (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PositionValveSet', ... (0 bytes))
ebusd/bai/PositionValveSet (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PowerValue', ... (0 bytes))
ebusd/bai/PowerValue (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrAPSCounter', ... (0 bytes))
ebusd/bai/PrAPSCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrAPSSum', ... (0 bytes))
ebusd/bai/PrAPSSum (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredCombustionDecrementTime', ... (0 bytes))
ebusd/bai/PredCombustionDecrementTime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredCombustionPredCounter', ... (0 bytes))
ebusd/bai/PredCombustionPredCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredCombustionSwitchingPoint', ... (0 bytes))
ebusd/bai/PredCombustionSwitchingPoint (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredFanPWMDevThreshold', ... (0 bytes))
ebusd/bai/PredFanPWMDevThreshold (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredFanPWMPredCounter', ... (0 bytes))
ebusd/bai/PredFanPWMPredCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredFanPWMRefPWMcounter', ... (0 bytes))
ebusd/bai/PredFanPWMRefPWMcounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredFanPWMRefPWMsum', ... (0 bytes))
ebusd/bai/PredFanPWMRefPWMsum (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredFanPWMSwitchingPoint', ... (0 bytes))
ebusd/bai/PredFanPWMSwitchingPoint (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredIgnitionPredCounter', ... (0 bytes))
ebusd/bai/PredIgnitionPredCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredIgnitionSwitchingPoint', ... (0 bytes))
ebusd/bai/PredIgnitionSwitchingPoint (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredSourcePressureDevThreshold', ... (0 bytes))
ebusd/bai/PredSourcePressureDevThreshold (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredSourcePressurePredCounter', ... (0 bytes))
ebusd/bai/PredSourcePressurePredCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredSourcePressureSwitchingPoint', ... (0 bytes))
ebusd/bai/PredSourcePressureSwitchingPoint (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredWaterflowDevThreshold', ... (0 bytes))
ebusd/bai/PredWaterflowDevThreshold (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredWaterflowSwitchingPoint', ... (0 bytes))
ebusd/bai/PredWaterflowSwitchingPoint (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredWaterpressureMaxPressure', ... (0 bytes))
ebusd/bai/PredWaterpressureMaxPressure (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredWaterpressureMinPressure', ... (0 bytes))
ebusd/bai/PredWaterpressureMinPressure (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PredWaterpressureSwitchingPoint', ... (0 bytes))
ebusd/bai/PredWaterpressureSwitchingPoint (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergyCountHc1', ... (0 bytes))
ebusd/bai/PrEnergyCountHc1 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergyCountHc2', ... (0 bytes))
ebusd/bai/PrEnergyCountHc2 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergyCountHc3', ... (0 bytes))
ebusd/bai/PrEnergyCountHc3 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergyCountHwc1', ... (0 bytes))
ebusd/bai/PrEnergyCountHwc1 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergyCountHwc2', ... (0 bytes))
ebusd/bai/PrEnergyCountHwc2 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergyCountHwc3', ... (0 bytes))
ebusd/bai/PrEnergyCountHwc3 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergySumHc1', ... (0 bytes))
ebusd/bai/PrEnergySumHc1 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergySumHc2', ... (0 bytes))
ebusd/bai/PrEnergySumHc2 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergySumHc3', ... (0 bytes))
ebusd/bai/PrEnergySumHc3 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergySumHwc1', ... (0 bytes))
ebusd/bai/PrEnergySumHwc1 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergySumHwc2', ... (0 bytes))
ebusd/bai/PrEnergySumHwc2 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PrEnergySumHwc3', ... (0 bytes))
ebusd/bai/PrEnergySumHwc3 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PumpHours', ... (0 bytes))
ebusd/bai/PumpHours (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PumpHwcFlowNumber', ... (0 bytes))
ebusd/bai/PumpHwcFlowNumber (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PumpHwcFlowSum', ... (0 bytes))
ebusd/bai/PumpHwcFlowSum (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReduceModulationBlocktime', ... (0 bytes))
ebusd/bai/ReduceModulationBlocktime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReduceModulationBlocktime', ... (0 bytes))
ebusd/bai/ReduceModulationBlocktime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/RemainingBoilerblocktime', ... (0 bytes))
ebusd/bai/RemainingBoilerblocktime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReturnRegulation', ... (0 bytes))
ebusd/bai/ReturnRegulation (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReturnRegulation', ... (0 bytes))
ebusd/bai/ReturnRegulation (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReturnTemp', ... (101 bytes))
ebusd/bai/ReturnTemp {
"temp": {"value": 30.56},
"tempmirror": {"value": 65046},
"sensor": {"value": "ok"}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReturnTempMax', ... (0 bytes))
ebusd/bai/ReturnTempMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SecondPumpMode', ... (0 bytes))
ebusd/bai/SecondPumpMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SecondPumpMode', ... (0 bytes))
ebusd/bai/SecondPumpMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SerialNumber', ... (0 bytes))
ebusd/bai/SerialNumber (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SetFactoryValues', ... (0 bytes))
ebusd/bai/SetFactoryValues (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SetFactoryValues', ... (0 bytes))
ebusd/bai/SetFactoryValues (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SetMode', ... (384 bytes))
ebusd/bai/SetMode {
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 36.5},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 0},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 1},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SHEMaxDeltaHwcFlow', ... (0 bytes))
ebusd/bai/SHEMaxDeltaHwcFlow (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SHEMaxFlowTemp', ... (0 bytes))
ebusd/bai/SHEMaxFlowTemp (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SolPostHeat', ... (0 bytes))
ebusd/bai/SolPostHeat (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SpecialAdj', ... (0 bytes))
ebusd/bai/SpecialAdj (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SpecialAdj', ... (0 bytes))
ebusd/bai/SpecialAdj (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Statenumber', ... (0 bytes))
ebusd/bai/Statenumber (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status01', ... (272 bytes))
ebusd/bai/Status01 {
"0": {"name": "temp1", "value": 30.0},
"1": {"name": "temp1", "value": 30.0},
"2": {"name": "temp2", "value": 12.250},
"3": {"name": "temp1", "value": 31.0},
"4": {"name": "temp1", "value": 33.0},
"5": {"name": "pumpstate", "value": "off"}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status02', ... (221 bytes))
ebusd/bai/Status02 {
"0": {"name": "hwcmode", "value": "auto"},
"1": {"name": "temp0", "value": 60},
"2": {"name": "temp1", "value": 70.0},
"3": {"name": "temp0", "value": 70},
"4": {"name": "temp1", "value": 48.0}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status16', ... (0 bytes))
ebusd/bai/Status16 (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status', ... (0 bytes))
ebusd/bai/Status (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Storageloadpump', ... (0 bytes))
ebusd/bai/Storageloadpump (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageLoadPumpHours', ... (0 bytes))
ebusd/bai/StorageLoadPumpHours (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageloadPumpStarts', ... (0 bytes))
ebusd/bai/StorageloadPumpStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageLoadTimeMax', ... (0 bytes))
ebusd/bai/StorageLoadTimeMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageLoadTimeMax', ... (0 bytes))
ebusd/bai/StorageLoadTimeMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StoragereleaseClock', ... (0 bytes))
ebusd/bai/StoragereleaseClock (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageTemp', ... (0 bytes))
ebusd/bai/StorageTemp (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageTempDesired', ... (0 bytes))
ebusd/bai/StorageTempDesired (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/StorageTempMax', ... (0 bytes))
ebusd/bai/StorageTempMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TargetFanSpeed', ... (0 bytes))
ebusd/bai/TargetFanSpeed (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TargetFanSpeedOutput', ... (0 bytes))
ebusd/bai/TargetFanSpeedOutput (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TempDiffBlock', ... (0 bytes))
ebusd/bai/TempDiffBlock (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TempDiffFailure', ... (0 bytes))
ebusd/bai/TempDiffFailure (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TempGradientFailure', ... (0 bytes))
ebusd/bai/TempGradientFailure (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Templimiter', ... (0 bytes))
ebusd/bai/Templimiter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TemplimiterWithNTC', ... (0 bytes))
ebusd/bai/TemplimiterWithNTC (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TempMaxDiffExtTFT', ... (0 bytes))
ebusd/bai/TempMaxDiffExtTFT (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/TimerInputHc', ... (0 bytes))
ebusd/bai/TimerInputHc (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ValveMode', ... (0 bytes))
ebusd/bai/ValveMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ValveMode', ... (0 bytes))
ebusd/bai/ValveMode (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ValveStarts', ... (0 bytes))
ebusd/bai/ValveStarts (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/VolatileLockout', ... (0 bytes))
ebusd/bai/VolatileLockout (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WarmstartDemand', ... (0 bytes))
ebusd/bai/WarmstartDemand (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WarmstartOffset', ... (0 bytes))
ebusd/bai/WarmstartOffset (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WaterHcFlowMax', ... (0 bytes))
ebusd/bai/WaterHcFlowMax (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WaterPressure', ... (65 bytes))
ebusd/bai/WaterPressure {
"press": {"value": 1.550},
"sensor": {"value": "ok"}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WaterpressureBranchControlOff', ... (0 bytes))
ebusd/bai/WaterpressureBranchControlOff (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WaterpressureMeasureCounter', ... (0 bytes))
ebusd/bai/WaterpressureMeasureCounter (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WaterpressureVariantSum', ... (0 bytes))
ebusd/bai/WaterpressureVariantSum (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WP', ... (0 bytes))
ebusd/bai/WP (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPPostrunTime', ... (0 bytes))
ebusd/bai/WPPostrunTime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPPostrunTime', ... (0 bytes))
ebusd/bai/WPPostrunTime (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPPWMPower', ... (32 bytes))
ebusd/bai/WPPWMPower {
"percent0": {"value": 0}}
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPPWMPowerDia', ... (0 bytes))
ebusd/bai/WPPWMPowerDia (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPPWMPowerDia', ... (0 bytes))
ebusd/bai/WPPWMPowerDia (null)
Client mosqsub/10880-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPSecondStage', ... (0 bytes))
ebusd/bai/WPSecondStage (null)
@Beta-User
diese Version "ebusd 3.3.v3.3-19-ga3f4999" läuft nun ebenfalls am Testsystem.
LG
gleich noch eine Frage an John!
Sehe ich das jetzt richtig, dass mit "list" nur der Cache des Dämon angefragt wird und keine "echte" (forced) Busanfrage stattfindet?
LG
Zitat von: Reinhart am 08 April 2019, 18:59:33
@Beta-User
diese Version "ebusd 3.3.v3.3-19-ga3f4999" läuft nun ebenfalls am Testsystem.
LG
Thx. Mit
attr DEVICE setList getKnown:noArg DEV_ID/global/list onlyknownbzw. Auslösen des set scheint jetzt einiges an Info zu kommen. Ich würde daher mal ein "set DEVICE getknown" ans Ende des template schreiben. Komplett sähe das dann so aus:
name:E_01a_eBus_daemon_splitter
filter:TYPE=MQTT2_DEVICE
desc:Device containing all status messages from the ebus daemon itself<br>NOTE: acts also as a bridge device to split up the hardware on the bus into different mqtt2_devices<br>NOTE:<br>- for use with MQTT2_CLIENT use a copy of the Device with the same clientId than the IO, delete original's readingList after applying the template!<br>- this might change the devices CID
par:DEVTYPE;Internal TYPE of the device; { InternalVal("DEVICE","TYPE","")}
par:DEV_ID;base topic set ebus;{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:?(ebus[a-zA-Z])[^/]*[/].*:, ? $1 : "ebusd" }
modify DEVICE DEV_ID
attr DEVICE autocreate 1
attr DEVICE bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr DEVICE icon sani_boiler_temp
attr DEVICE userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
attr DEVICE stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr DEVICE setList getKnown:noArg DEV_ID/global/list onlyknown
set DEVICE getKnown
attr DEVICE model E_01a_eBus_daemon_splitterMagst du das file auf dem Testystem mal entsprechend anpassen, die ebus-Devices komplett löschen, save drauf, und dann nochmal schauen, ob das template nach Anwendung auf das dann wieder "nackige" ebusd-MQTT2-Sammel-Device erwartungsgemäß alles sauber sortiert und den ebusd so anpingt, dass wir gleich eine halbwegs komplette Übersicht (also bezogen auf das Testsystem: alle drei die Hardware repräsentierenden Geräte) haben?
habe das jetzt gemacht, aber bei "global" kommt gar nichts.
ZitatPlease note that the global topic prefix is not published again by the /list suffix.
LG
Zitat von: Reinhart am 08 April 2019, 20:35:31
habe das jetzt gemacht, aber bei "global" kommt gar nichts.
LG
Hmm,
die global-Dinge landen sauber im ebusd-Gerät selbst; das ist durch die bridgeRegexp so eingestellt.
Aber der "bai" scheint verschwunden zu bleiben?
da haben wir uns mißverstanden, dieses "global" funktioniert nicht:
getKnown:noArg ebusd/global/list onlyknown
so gehts
getKnown430:noArg ebusd/430/list onlyknown
getKnownBai:noArg ebusd/bai/list onlyknown
Warum die "bai" nicht gekommen sind war der Dämon, er hat alles geliefert nur keine "bai". Ein Restart des Dämon hat das Problem behoben.
LG
Hmm, Danke für die Rückmeldung.
Mit dieser spezifischen Form der "list"-Abfrage beißt sich aber die Katze wieder in den Schwanz: wir wollten doch eigentlich eine Abfragefunktionalität haben, mit der man feststellen kann, was am Bus alles so verfügbar ist. So müßen erst wieder die Zielbaugruppen angegeben werden, die "wir" ja noch gar nicht kennen...
Diese spezifische Art der Abfrage würde ich daher eher bei den einzelnen Devices unterbringen wollen (dort dann aber wieder ohne den Zusatz 430 bzw Bai).
Nach den Äußerungen von John30 klang das aber danach, als wäre die globale Abfrage "einen Level höher" angedacht. Oder habe ich schlicht den falschen Pfad erwischt?
Dass "bai" wieder da war, und dann auch das entsprechende Device sauber angelegt wurde, habe ich vorhin gesehen, danke.
es geht nur die Topic "global" nicht, das was du suchst, findet man ohne "global".
set Mosquitto publish ebusd/list onlyknown
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/list', ... (9 bytes))
ebusd/list onlyknown
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/Date', ... (39 bytes))
ebusd/430/Date {
"date": {"value": "08.04.2019"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/Hc1HeatCurve', ... (32 bytes))
ebusd/430/Hc1HeatCurve {
"curve": {"value": 1.00}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/HwcTempDesired', ... (32 bytes))
ebusd/430/HwcTempDesired {
"temp1": {"value": 57.0}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/430/Time', ... (37 bytes))
ebusd/430/Time {
"time": {"value": "17:16:40"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/CounterStartattempts1', ... (30 bytes))
ebusd/bai/CounterStartattempts1 {
"temp0": {"value": 29}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DateTime', ... (145 bytes))
ebusd/bai/DateTime {
"dcfstate": {"value": "nosignal"},
"btime": {"value": "05:44:53"},
"bdate": {"value": "-.-.-"},
"temp2": {"value": 17.375}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/DeactivationsIFC', ... (38 bytes))
ebusd/bai/DeactivationsIFC {
"0": {"name": "", "value": 18}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanHours', ... (35 bytes))
ebusd/bai/FanHours {
"hoursum2": {"value": 6378}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FanSpeed', ... (37 bytes))
ebusd/bai/FanSpeed {
"0": {"name": "", "value": 0}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowTemp', ... (64 bytes))
ebusd/bai/FlowTemp {
"temp": {"value": 25.88},
"sensor": {"value": "ok"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/FlowTempDesired', ... (32 bytes))
ebusd/bai/FlowTempDesired {
"temp": {"value": 29.50}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcHours', ... (35 bytes))
ebusd/bai/HcHours {
"hoursum2": {"value": 5466}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HcStarts', ... (41 bytes))
ebusd/bai/HcStarts {
"0": {"name": "", "value": 39800}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcHours', ... (34 bytes))
ebusd/bai/HwcHours {
"hoursum2": {"value": 686}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcSetPotmeter', ... (32 bytes))
ebusd/bai/HwcSetPotmeter {
"temp": {"value": 48.94}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/HwcStarts', ... (41 bytes))
ebusd/bai/HwcStarts {
"0": {"name": "", "value": 88600}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/OutdoorstempSensor', ... (64 bytes))
ebusd/bai/OutdoorstempSensor {
"temp": {"value": 17.38},
"sensor": {"value": "ok"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/PartloadHcKW', ... (30 bytes))
ebusd/bai/PartloadHcKW {
"power": {"value": 18}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/ReturnTemp', ... (101 bytes))
ebusd/bai/ReturnTemp {
"temp": {"value": 24.38},
"tempmirror": {"value": 65145},
"sensor": {"value": "ok"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/SetMode', ... (384 bytes))
ebusd/bai/SetMode {
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 29.5},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 0},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 1},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status01', ... (272 bytes))
ebusd/bai/Status01 {
"0": {"name": "temp1", "value": 25.0},
"1": {"name": "temp1", "value": 24.0},
"2": {"name": "temp2", "value": 17.375},
"3": {"name": "temp1", "value": 35.0},
"4": {"name": "temp1", "value": 36.0},
"5": {"name": "pumpstate", "value": "off"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/Status02', ... (221 bytes))
ebusd/bai/Status02 {
"0": {"name": "hwcmode", "value": "auto"},
"1": {"name": "temp0", "value": 60},
"2": {"name": "temp1", "value": 70.0},
"3": {"name": "temp0", "value": 70},
"4": {"name": "temp1", "value": 48.0}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WaterPressure', ... (65 bytes))
ebusd/bai/WaterPressure {
"press": {"value": 1.514},
"sensor": {"value": "ok"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/bai/WPPWMPower', ... (32 bytes))
ebusd/bai/WPPWMPower {
"percent0": {"value": 0}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/broadcast/outsidetemp', ... (34 bytes))
ebusd/broadcast/outsidetemp {
"temp2": {"value": 15.375}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/broadcast/vdatetime', ... (75 bytes))
ebusd/broadcast/vdatetime {
"time": {"value": "17:16:55"},
"date": {"value": "08.04.2019"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.08/', ... (126 bytes))
ebusd/scan.08/ {
"MF": {"value": "Vaillant"},
"ID": {"value": "BAI00"},
"SW": {"value": "0518"},
"HW": {"value": "7401"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.08/id', ... (211 bytes))
ebusd/scan.08/id {
"prefix": {"value": ""},
"year": {"value": ""},
"week": {"value": ""},
"product": {"value": ""},
"supplier": {"value": ""},
"counter": {"value": ""},
"suffix": {"value": ""}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.15/', ... (126 bytes))
ebusd/scan.15/ {
"MF": {"value": "Vaillant"},
"ID": {"value": "43000"},
"SW": {"value": "0215"},
"HW": {"value": "2002"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/scan.15/id', ... (239 bytes))
ebusd/scan.15/id {
"prefix": {"value": "21"},
"year": {"value": "11"},
"week": {"value": "09"},
"product": {"value": "0020028515"},
"supplier": {"value": "0907"},
"counter": {"value": "006374"},
"suffix": {"value": "N5"}}
Client mosqsub/22694-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/global/uptime', ... (5 bytes))
ebusd/global/uptime 81804
hier werden alle Geräte aufgelistet, aber auch nur deshalb weil sie bereits durch autocreate erfasst wurden, also einmal schon Daten abgefragt wurden. Ohne "onlyknown" werden alle Geräte gefunden die per CSV geladen wurden. Die kann ich aber hier nich tposten, weil der Code Tag das nicht packt.
LG
Argh, manchmal ist es so einfach...
Die readingList mit den ganzen Einträgen ohne Content wird jetzt zumindest beim 430 auch wieder so lang, dass das nicht optimal ist, oder? Schwierig, da zu sagen, was Sinn macht.
Einfach so ohne Parameter würde ich das also nicht ins template nehmen und aufrufen, wenn dann gibt es eben noch einen zweiten Eintrag "getAll", der dann den publish ohne payload macht?
Bisher hatte ich verstanden, dass sich das auf der ebusd-Seite schon automatisch irgendwann füllen würde, und man dann lediglich den erstmaligen publish veranlassen würde. Das wäre m.E. eigentlich die richtige Vorgehensweise.
also die /global Elemente sind so speziell und völlig unabhängig von vom Scan Ergebnis und der Anlagenkonfiguration, dass ich das (fürst Erste) nicht ins /list Result mit aufgenommen habe. Wenn ihr das unbedingt braucht, kann ich es schon noch einbauen.
Genau, /list löst by intention niemals einen Bus Request aus.
Moin,
dass ".../global/list" nichts liefert, ist m.E. ok so, das war von meiner Seite zu kurz gedacht.
Das "list" allg. ohne request ist an sich auch ok, wir wollten ja eine größere Belastung des Bus vermeiden.
Wenn dann aber jetzt die Situation die ist, dass wir doch erst spezifisch abfragen müssen, bevor überhaupt irgendwas via MQTT gepublisht wird, stehen wir eigentlich wieder am Anfang.
Oder anders gewendet: weiß jemand, der den ebusd einsetzt "sowieso", was da ist und kann dann die Abfragen auch ohne "unsere" Hilfe bei MQTT2 erstellen? Beispielsweise, weil er den Dämon nur sinnvoll konfiguriert bekommt, wenn er das passende csv wählt? Aus der csv-Benennung ergibt sich dann der Topic-Pfad, oder? Und aus den Angaben im csv dann die Reading-Benennung? Dann müßte man ggf. nur die Doku anpassen bzw. entsprechend ergänzen (jedenfalls, soweit mir das im Kopf ist)?
Vorläufig habe ich mal beide Abfragen in die setList eingebaut.
Zitat von: Beta-User am 10 April 2019, 07:42:22
Oder anders gewendet: weiß jemand, der den ebusd einsetzt "sowieso", was da ist und kann dann die Abfragen auch ohne "unsere" Hilfe bei MQTT2 erstellen? Beispielsweise, weil er den Dämon nur sinnvoll konfiguriert bekommt, wenn er das passende csv wählt? Aus der csv-Benennung ergibt sich dann der Topic-Pfad, oder? Und aus den Angaben im csv dann die Reading-Benennung? Dann müßte man ggf. nur die Doku anpassen bzw. entsprechend ergänzen (jedenfalls, soweit mir das im Kopf ist)?
Vorläufig habe ich mal beide Abfragen in die setList eingebaut.
Bei der Konfiguration hat der Anwender mit der CSV normalerweise nichts zu tun, außer bei Exoten. Der Dämon wählt die CSV aus der Information die er aus der Scan bekommt selbst aus. Aber die "List" die uns John jetzt eingebaut hat den großen Vorteil, das sie erstens den Bus nicht belastet und der Anwender alle für ihn in frage kommenden Messwerte auf einen Blick sieht. Man braucht dann nur den Namen kopieren und in die Abfrage den get Befehl dazu hängen.
Wenn dass über die Gui funktionieren würde, wäre es der Überhammer. So was ähnliches hat "jamesgo" schon mit dem Modul "98_GAEBUS" realisiert, aber auf Basis Telnet. Im Prinzip könnte man das Modul modifizieren und mit diesem den "Set" Eintrag für die Abfrage automatisch vornehmen lassen.
Eine andere Möglichkeit wäre, man läßt GAEBUS so wie er ist und dient zur Abfrage der gewünschten Messwerte (hier kann man auch die Zeit einstellen wie oft er abfragen soll) , aber dann müsste uns John zusätzlich eine MQTT Antwort einbauen wenn eine Telnet Abfrage erfolgt. Mit dieser Maßnahme würde dann über autocreate ebenfalls das Reading angelegt. Da ich aber die interne Struktur vom Dämon nicht kenne, weiß ich nicht ob das so einfach ist.
Ganz sauber ist beides nicht, aber machbar wäre es. Der Wissenstand der User die den eBus benutzen ist außerdem auch sehr unterschiedlich, Einsteiger tun sich in der Regel etwas schwerer, aber es gibt auch Leute die viel lesen und die kennen den Umgang damit perfekt. Die Templates sind aber für beide Zielgruppen ideal geeignet.
Damit du siehst wie das funktioniert, habe ich am Testserver GAEBUS installiert.
LG
Zitat von: Reinhart am 10 April 2019, 09:43:23
Wenn dass über die Gui funktionieren würde, wäre es der Überhammer. So was ähnliches hat "jamesgo" schon mit dem Modul "98_GAEBUS" realisiert, aber auf Basis Telnet. Im Prinzip könnte man das Modul modifizieren und mit diesem den "Set" Eintrag für die Abfrage automatisch vornehmen lassen.
ich dachte der Plan ist, ohne GAEBUS auszukommen?
Zitat von: Reinhart am 10 April 2019, 09:43:23
Eine andere Möglichkeit wäre, man läßt GAEBUS so wie er ist und dient zur Abfrage der gewünschten Messwerte (hier kann man auch die Zeit einstellen wie oft er abfragen soll) , aber dann müsste uns John zusätzlich eine MQTT Antwort einbauen wenn eine Telnet Abfrage erfolgt. Mit dieser Maßnahme würde dann über autocreate ebenfalls das Reading angelegt. Da ich aber die interne Struktur vom Dämon nicht kenne, weiß ich nicht ob das so einfach ist.
Ganz sauber ist beides nicht, aber machbar wäre es. Der Wissenstand der User die den eBus benutzen ist außerdem auch sehr unterschiedlich, Einsteiger tun sich in der Regel etwas schwerer, aber es gibt auch Leute die viel lesen und die kennen den Umgang damit perfekt. Die Templates sind aber für beide Zielgruppen ideal geeignet.
also ein Hybrid von ebusd client Port und MQTT macht aus meiner Perspektive nun wirklich keinen Sinn. Ziel sollte es doch sein, nur via MQTT auszukommen, oder nicht?
Und mit dem /list kommen ja dann auch alle Elemente vorbei, womit die Liste dann definitiv vollständig wird. Kann höchstens sein, dass das nicht sofort nach ebusd Neustart komplett ist weil der Scan noch nicht abgeschlossen ist. Das lässt sich aber auch an eingehenden Topics mit scan. Präfix erkennen, so dass eigentlich kein User Eingriff oder zeitbasiertes erneutes Nachfragen des /list notwendig ist.
Aber vielleicht habe ich auch eure Ziele nicht richtig verstanden :)
Sehe das auch so, dass es zukünftig reichen soll, nur MQTT einzusetzen.
Und wenn alle mit /list übermittelten Datenelemente potentiell (nach einer entsprechenden Abfrage) mit Leben gefüllt sein können, dann ist es auch ok, wenn die Liste lang ist; ich würde nur vermeiden wollen, dass der unbedarfte user sich mit unnötigem Ballast rumschlagen muß, den er definitiv nie benötigt.
Damit würde es Sinn machen, die automatische Abfrage durch das template ohne payload zu machen, oder? Danach würde sich das Spielfeld auf die setList und getList-Gestaltung bei den einzelnen Busteilnehmern verlagern?
Da sollten dann (via template) die häufig benötigten Infos rein, und m.E. sollte man auch das at so gestalten, dass dort keine IO-Publish-Anweisungen drinstehen, sondern die "get"-Anwfragen. Ist zwar im Prinzip dasselbe wie IO-Publish, aber zum einen scheint mir das für die User nicht so verständlich zu sein wie eine Werteabfrage mit "get", zum anderen hatten wir jedenfalls früher den Effekt, dass die readingList damit unnötig lang wurde (weil auch die get-Anfragen drin waren).
Also für den 430 die Elemente "Hc1HeatCurve_curve_value", "HwcTempDesired_temp1_value", und eventuell "Date_date_value"+"Time_time_value", für den bai die Dinge, die jetzt in dem at stehen.
Braucht ihr da Hilfe?
@Reinhart: Auf dem Testsystem ist jetzt ein Gerät MQTT2_ebusd_3.3_15145 vorhanden, das es mit dieser readingList eigentlich nicht geben dürfte: attr MQTT2_ebusd_3.3_15145 readingList ebusd_3.3_15145:ebusd/430/Hc1NightTemp:.* { json2nameValue($EVENT, 'Hc1NightTemp_', $JSONMAP) }
Funktioniert die bridgeRegexp des splitters nicht ordnungsgemäß oder gibt es eine andere Erklärung?
Nein, die bridgeregexp passt schon, da habe ich mit GAEBUS experimentiert und dort das Gerät aktiviert, somit wurde es durch autocreate sofort erfasst. Warum es ursprünglich nach ... 3.3.. gewandert ist weiß ich auch nicht, habe es dort gelöscht und dann wurde es ordnungsgemäß im ebusd/430 angelegt.
Ja, John hat schon recht rein bei MQTT zu bleiben und soviel Komfort kann man den Anwendern gar nicht anbieten. Wenn jemand ein Template für Sonoff installiert und gar kein Sonoff hat, dann funktioniert das logischerweise nicht und genau da hört der Komfort auf. Genau so verhält es sich beim eBus wenn jemand ein Template für die Calormatic installiert und gar keine hat wird es auch nicht klappen.
Der einzige Weg von Null weg zu installieren bleibt daher das Scan Ergebnis und das automatisch auszuwerten ist etwas komplex. Ich glaube aber, dass die meisten Anwender vom eBus schon wissen welche Geräte sie haben und auf das richtige Template klicken. Daher muss man halt im Wiki gezielt auf die richtige Reihenfolge der Installation hinweisen und das sie selbst dafür sorgen müssen das diese Readings auch abgefragt werden.
Mir fällt zumindest nichts ein wie man das "at" automatisch befüllen kann. Mann müsste bei Auswahl des Template, das bestehende "at" mit "add" ( an die letzte Zeile dazuhängen ) erweitern. Aber was tun wenn sich der Anwender geirrt hat, dann sollte es wieder verschwinden. Einfacher wäre es zu jedem Template ein eigenes "at" zu erzeugen. Bin mir daher nicht sicher ob man das Thema "at" weiter verfolgen soll.
LG
Danke mal für die Rückmeldung zur bridgeRegexp.
Was das at angeht, ist es schade, dass es nicht reicht, die "Ziel-Devices" jeweils mit einer getList zu versorgen und dann mit passenden Regex zu operieren. Also ins Unreine in etwa so:defmod EBUS.TIMER at +*00:30:00 get TYPE=MQTT2_DEVICE:FILTER=CID=ebus._.* .*
Es wäre sicher möglich, eine myUtils-Funktion zu bauen, die die verfügbaren get's vorab ermittelt und dann gezielt abruft. Allerdings ist das insgesamt nicht wirklich manipulationssicher, da ist es vermutlich wirklich besser, den Anwender auf das manuelle Editieren des einen at zu verweisen (aufteilen macht für mich nicht den großen Sinn, und auch als Helfer ist es dann schwieriger, gezielt rückzufragen).
Trotzdem würde ich das eher als get-Aufrufe in dem at gestalten und dann die getLists an den Devices entsprechend (per template) setzen.
Da es hier schon eine ganze Zeit ruhig ist:
Ist das ganze Thema jetzt eigentlich soweit auf Stand oder gibt es im Moment noch irgendwas, wo ich unterstützen könnte oder soll?
War das nicht so das die mqtt2.ebus.template per update verteilt wurde ?
Auf einem Test-System mit heutigem update ist sie nicht in AttrTemplate ???
Gruß
Thomas
Nein, wurde noch nie per Update verteilt und du findest es als Attachment hier (https://forum.fhem.de/index.php/topic,79600.msg878716.html#msg878716)!
LG
Wenn das deine aktuelle ist wäre die dann nicht besser im ersten Post angehängt wie im Wiki verlinkt ?
Hmm,
wir hatten das ja damals nicht in die "allgemeine" File aufgenommen, weil es nur für eine kleine Zahl von Usern relevant ist.
Zwischenzeitlich hat Rudi das "prereq:" eingebaut. Das würde es ziemlich sicher möglich machen, diese templates für die user "auszubauen", die kein ebus-Splitter-Device definiert haben. Mein Vorschlag wäre, das einzubauen und auch diese templates via svn direkt mit zu veröffentlichen.
Die weiteren Fragen wäre dann, ob
- die Verteilung im allgemeinen file (mqtt2.template) erfolgen soll oder weiter separat (durch einen anderen Maintainer ;) ). Letzteres wäre mir lieber, denn diese templates sind soweit ich mich entsinne teilweise etwas "speziell" und es wäre sinnvoll, wenn jemand das betreuen würde, der auch passende Hardware hat. Andererseits ist die Frequenz der updates zwischenzeitlich "gering"...
- weitere Software (myUtils) erforderlich ist, um (manches) sinnvoll zu nutzen. Dann könnte man auch den Teil (nach contrib ?) einchecken und eventuell über einen template-Befehl die File bei Bedarf ins Modulverzeichnis schieben und gleich laden.
(Ist alles Neuland, erscheint mir aber nicht sooo schwierig; evtl. könnte man Rudi mal fragen, ob wir eine allgemeine Routine bekommen, um einzelne "subs" in eine "allgemeine" 99_attrTemplateFunctions.pm automatisiert einzufügen bzw. dort auszutauschen; das "Problem" taucht meinem Bauchgefühl nach zukünftig häufiger auf, aktuell wäre es heute schon z.B. bei Rockrobo vorhanden.).
Ich schlage separate 99_XXX.pm Dateien vor, je nach Themengebiet separiert, damit kann man sie auch mit version auswerten.
Damit man sie im template einfacher vom SVN-Server herunterladen kann (contrib wird per update nicht aktualisiert), habe ich gerade in 99_Utils.pm eine Funktion eingebaut:{ Svn_GetFile("contrib/86_FS10.pm", "FHEM/86_FS10.pm") }
Das mit den separaten 99-ern klingt plausibel, dann kann man ggf. auch eine kleine Commandref dazu packen.
Wenn ich den commit im svn richtig lese, müßte man hinterher noch einen reload im template ausführen? (Wenn ja: wäre ein optionales drittes Argument möglich, damit die Datei nach dem Download gleich geladen wird? Wenn nein: Ist sichergestellt, dass bei einem reload-Befehl via template die Datei schon da ist?)
Mit dieser Option würde ich jetzt Folgendes vorschlagen:
- Das separate attrTemplate-File erhalten, Download aus dem svn nur bei Bedarf (=durch Anwenden des in der allg. File enthaltenen Basis-templates).
- die myUtils käme dann erst, wenn man auch eines der readingsGroup-Devices via attrTemplate generiert?
- für die attrTemplate-Sachen lege ich ein neues Verzeichnis in contrib (AttrTemplate) an und trage mich mal als Maintainer für das Verzeichnis ein. Wer einzelne Dateien darau "haben will", kann das gerne tun.
- Den Code aus dem Wiki (https://wiki.fhem.de/wiki/EBUS-MQTT2#myUtils-Code) übernehme ich in eine eigene myUtils-Datei, Namensschema tendenziell sowas wie "99_attrT_ebus_Utils.pm", der Funktionsname muß dann aber etwas "spezieller und generischer" werden, damit besser erkennbar ist, wo eine Funktion herkommt. Ich tendiere zu sowas wie "attrT_ebus_<Funktion>()", konkret also "attrT_ebus_createBarView".
(Zur Funktion selbst würde ich gerne noch zwei optionale Parameter sehen, nämlich $maxValue und die Farbe, rot wäre mir persönlich zu "signalig". Vielleicht mag sich das und das cref-Thema dazu noch jemand anderes ansehen? ;) ). Wenn das eine "allgemein wünschenswerte" Funktion ist, die auch woanders benötigt werden könnte, wäre es vermutlich auch kein Problem, zu fragen, ob das in einer generalisierten Variante (z.B. nach Color.pm => justme1968 ansprechen) eingecheckt werden könnte... (Macht evtl. Sinn, ich sehe grade, dass das im Prinzip eine 1:1 Kopie aus den Beispielen zu readingsGroup im Wiki (https://wiki.fhem.de/wiki/ReadingsGroup#Einfache_Balkendiagramme) ist...).
Rückmeldung erbeten...!
Ich habe den dritten Parameter hinzugefuegt, damit schaut es so aus:{ Svn_GetFile("contrib/86_FS10.pm", "FHEM/86_FS10.pm", sub(){CommandReload(undef, "86_FS10")}) }
Zitat von: rudolfkoenig am 17 Januar 2020, 14:26:51
Ich habe den dritten Parameter hinzugefuegt
Herzlichen Dank!
Wie immer weiter gedacht als mein Vorschlag, damit bekommen wir auch die Initialisierung neuer Templates gleich erschlagen :) .
Um den Mechanismus mal zu testen, würde ich die beiden angehängten Files bei nächster Gelegenheit einchecken. Ggf. der letzten Version von Reinhart ist da nur der Name der Funktion auf die separate myUtils-File geändert und die Funktionsweise dynamisiert. Ist völlig ungetestet, und kann daher Fehler verursachen, kann nicht mehr sagen, als dass das Ding läd...
Dringende BITTE daher, das zu testen und Rückmeldung zu geben, was ggf. geändert werden soll.
Hallo zusammen,
nachdem sowieso ein paar Änderungen für weitere Tests hier und anderswo sinnvoll waren, habe ich vorhin einiges ins svn geschubst, die in leicht veränderter Form das hier umsetzen sollte:
Zitat von: Beta-User am 17 Januar 2020, 13:46:57
Mit dieser Option würde ich jetzt Folgendes vorschlagen:
- Das separate attrTemplate-File erhalten, Download aus dem svn nur bei Bedarf (=durch Anwenden des in der allg. File enthaltenen Basis-templates).
- die myUtils käme dann erst, wenn man auch eines der readingsGroup-Devices via attrTemplate generiert?
- für die attrTemplate-Sachen lege ich ein neues Verzeichnis in contrib (AttrTemplate) an und trage mich mal als Maintainer für das Verzeichnis ein. Wer einzelne Dateien darau "haben will", kann das gerne tun.
- Den Code aus dem Wiki (https://wiki.fhem.de/wiki/EBUS-MQTT2#myUtils-Code (https://wiki.fhem.de/wiki/EBUS-MQTT2#myUtils-Code)) übernehme ich in eine eigene myUtils-Datei, Namensschema tendenziell sowas wie "99_attrT_ebus_Utils.pm", der Funktionsname muß dann aber etwas "spezieller und generischer" werden, damit besser erkennbar ist, wo eine Funktion herkommt. Ich tendiere zu sowas wie "attrT_ebus_<Funktion>()", konkret also "attrT_ebus_createBarView".
(Zur Funktion selbst würde ich gerne noch zwei optionale Parameter sehen, [...]
Das "Problem" dabei ist Folgendes: Es ist bisher noch nicht getestet... ::) Notfalls hole ich das selbst nach, aber es wäre super, wenn sich da jemand für den ebus-Teil freiwillig melden würde und optimalerweise auch gleich den Wiki-Teil entsprechend aktualisieren, wenn es funktioniert wie gewünscht...?
Danke vorab!
Zitat von: Beta-User am 21 Januar 2020, 11:15:32
Notfalls hole ich das selbst nach, aber es wäre super, wenn sich da jemand für den ebus-Teil freiwillig melden würde und optimalerweise auch gleich den Wiki-Teil entsprechend aktualisieren, wenn es funktioniert wie gewünscht...?
Danke vorab!
Nachdem das an anderer Stelle (valetudo) ganz ordentlich funktioniert hat, und hier bisher keiner gemeldet hat, dass es nicht funktionieren würde: Im Wiki habe ich jetzt an drei Stellen (in den Praxisbeispielen und 2x in dem ebus-Artikel) den Hinweis aufgenommen, dass man jetzt nicht mehr den Code von hier holen muß, sondern dass das beides aus dem svn nachgeladen wird.
Es wäre nett, wenn jemand anderes sich den ebus-Artikel nochmal vonehmen könnte, um zukünftige Verwirrung zu vermeiden und die user darauf hinzuweisen, dass sie sich hierher wenden können, wenn Vorschläge dazu sind...?
Hallo zusammen,
nachdem Rudi vor einiger Zeit "periodicCmd" eingeführt hat, kurz die Frage, ob das at, auf das hier https://forum.fhem.de/index.php/topic,84636.msg1065426.html#msg1065426 verwiesen wird so weiter Bestand haben soll:
periodicCmd <cmd1>:<period1> <cmd2>:<period2>...
periodically execute the get or set command. The command will not take any arguments, create a new command without argument, if necessary. period is measured in minutes, and it must be an integer.Damit könnte man die Timer direkt in die templates mit einbauen. Weiß aber nicht, inwieweit wir damit ein Henne-Ei-Problem bekommen, denn afai remember mußte man erst eine Anfrage starten, um entsprechende Werte zurückzubekommen (und damit die Geräte von der bridgeRegexp anlegen zu lassen)?
Kann man sicher mit einem einmaligen Commando auch erreichen, vielleicht hat ja jemand eine zündende Idee dazu?
Grüße,
Beta-User
Lieg ich so daneben wenn ichs sage hier (https://forum.fhem.de/index.php/topic,97989.msg914297.html#msg914297) hat mal jemand eine zündende Idee gehabt ?
Hab ich gestern nämlich erst ausprobiert, bei mir klappt das irgendwie nicht mit dem getter, hab mich aber auch nur kurz mit beschäftigt und wieder sein lassen ;D
Hmm, hatte nur kurz ab hier reingesehen: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/mqtt2.ebus.template#L42
Da gibt's ne getList, und Klagen kamen dazu bisher auch nicht. (Ansonsten habe ich mich wirklich schon sehr lange nicht mehr mit diesen templates beschäftigt...).
Eventuell sollte man sich auch noch das Thema ignoreRegexp am IO in dem Zusammenhang mal ansehen, das ist auch was neues... (die get-Anweisungen brauchen wir eigentlich nicht in der readingList am Device, oder?)
Habs mir eben nochmal angeschaut, man muss die getList schon richtig definieren ::), dann klappt das mit periodicCmd problemlos.
attr MQTT2_ebusd_bai getList Hc1Heizkurveget:noArg Hc1Heizkurve ebusd/700/Hc1HeatCurve/get
attr MQTT2_ebusd_bai jsonMap Hc1HeatCurve_0_value:Hc1Heizkurve
attr MQTT2_ebusd_bai periodicCmd Hc1Heizkurveget:10
::)
Habe eben versucht, das irgendwie einem konkreten template zuzuordnen und bin etwas ratlos... Es müßte eigentlich zu eBus_4xx_devStateIcon_HeatCurve_HwcTemp hin, nicht zum bai-Gerät?
Aber wenn ich mir das so anschaue, ist das irgendwie gefühlt "noch nicht fertig", oder täuscht mich das?
Was die Namensvergabe des Readings (bzw. allg. der setter und (etwas weniger) der getter, sofern die wirklich unterscheidlich sein müssen (denke eigentlich nicht?)) angeht, bin ich auch nicht wirklich zufrieden. Eigentlich müßte man das mMn. ähnlich angehen wie im AV-Bereich und sowas wie standardisierte (englische) Readingnamen einführen.
Würe hier evtl. zu heatCurve führen, hat man mehrere, müßte man eben für jede je ein eigenes Device generieren und den Rest mittels "jsonMap xy:0" ausblenden.
Wie dem auch sei, im Moment weiß ich noch nicht so recht, wie ich mit der Info weitermachen kann. Hier wäre es wirklich gut, einen kompletten Vorschlag zu haben...
Da gibts nix zuzuordnen, hab die Templates nie wirklich genutzt/ausprobiert, ich hab mir ein Device (das heißt halt jetzt MQTT2_ebusd_bai) erstellt, welches mir alle nötigen Daten anzeigt, fertig.
Und das mit dem getList werd ich jetzt so in dem Device einbauen das ich mir das AT noch spare.
Mehr brauch und will ich nicht.
ZitatHi,
ausnahmsweise mal PM. :P
Beschäftigst dich doch auch mit dem Ebusd.
Wegen dem getter:
Der ist dort sehr nützlich und man spart sich das AT in Kombination mit periodicCmd:
@Otto123
die Ausnahme gefällt mir im Nachhinein nicht, hier oder sonst wo, wenn überhaupt, bitte weiter mit Rückmeldungen.
Gruß
Thomas
Hi @Beta-User,
Gerne antworte ich dir zum Beitrag/Anfrage von dir hier:
https://forum.fhem.de/index.php/topic,115185.msg1098310.html#msg1098310 (https://forum.fhem.de/index.php/topic,115185.msg1098310.html#msg1098310)
Ich hatte da schonmal bei justme1968 wegen Sprachsteuerung was angefragt.
siehe hier:
https://forum.fhem.de/index.php/topic,110531.0.html (https://forum.fhem.de/index.php/topic,110531.0.html)
Hier ging es mir um die Anzeige in der Alexa-App der einzelnen Modi´s (heat, auto etc...)
Ich habe halt in der server.js von HEAT auf current umgeschrieben, weil vorher immer HEAT in der App stand und erst nach Änderung alle Modi´s angezeigt wurden.
Hier habe ich das mapping aufgezeigt:
https://forum.fhem.de/index.php/topic,110531.msg1080791.html#msg1080791 (https://forum.fhem.de/index.php/topic,110531.msg1080791.html#msg1080791)
alexa-fhem version 0.5.27ZitatDas geht bei mir per Sprachbefehl:
"Alexa wie ist die Themperatur von der Heizung" (bei mir Aussentemperatur)
"Alexa wie ist der Status von der Heizung" (bei mir Aussentemperatur)
"Alexa wie ist die Heizung eingestellt" (Antwort= Modus+TargetTemperature)
"Alexa auf was ist die Heizung gestellt" (Antwort= Modus+TargetTemperature)
"Alexa stelle Heizung auf Auto"
"Alexa stelle Heizung auf Heizen"
"Alexa stelle Heizung auf Eco"
"Alexa stelle Heizung auf Kühlen" (Kühlen = Aus, habe ich auch so im mapping. Aus wird nicht unterstützt sagt sie sonst. k.a. warum).
TargetTemperature ist bei mir die Vorlauftemp. (nur als Anzeige).
Edit: was mir gerade auffällt, für TargetTemperature habe ich keine setlist, aber die Vorlauftemp. wird trotzdem angezeigt..
setList von Heizmodus:
Heizmodus:uzsuDropDown,on,off,auto,eco,low ebusd/hc/SetMode/set $EVTPART1und userReading vom heatingState:
heatingState { if (ReadingsVal($name,"Mode_hcmode1_value","-") eq "off"){"OFF"}
elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "on"){"HEAT"}
elsif (ReadingsVal($name,"Mode_hcmode1_value","auto") eq "auto"){"AUTO"}
elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "low"){"COOL"}
else {"ECO"}}Ich hatte auch schon zum Testen der TargetTemperature in der setList das:
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1hat auch funktioniert...
hier noch der link zu meiner hcmode:
https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908 (https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908)
Alle anderen Einstellungen mache ich am Tablet.
Die Heizung ist Aussentemperaturgeführt, also nicht mit Raumthermostat.
Wenn du sonst noch Infos brauchst oder ich was testen soll, dann sag Bescheid.
mfg mr_petz
Hmm, muß mir das mal intensiver ansehen.
Grundsätzlich würde ich lieber jsonMap nutzen, um "standardkonforme" Readings zu bekommen (und die dann auch in der setList zu verwenden), als herzugehen und ziemlich spezielle Mappings mit den automatischen Readingnamen vorzunehmen - eigentlich sollte es nämlich genügen, sowohl den Brenner wie einen (virtuellen?) Raumthermostaten als "thermostat" in genericDeviceType zu kennzeichen. Ggf. "müssen" wir auch sonst noch drumrum das eine oder andere anfassen, von daher würde ich das Angebot gerne annehmen, dass du da etwas rumtestest.
Von daher wäre meine Vorgehensweise mal die, dass ich einen Vorschlag für ein neues "Raumthermostat" mache. Dann könntest du dein bestehendes einfach kopieren und mit dem als Testgerät loslegen, dann wird evtl. manches klarer.
Zur Vorbereitung könntest du mal die Threads zu ems-esp und dem Fröhlich-Holzscheit-Ding suchen und durchsehen, falls du magst - da sind viele Aspekte in die Richtung schon verarbeitet...
Grundsätzlich würde ich dann künftig immer ein RAW-list vom ganzen Device benötigen, aber bitte erst, wenn ich den o.g. Vorschlag vorgelegt habe...
Zitat von: Beta-User am 04 November 2020, 22:24:56
Hmm, muß mir das mal intensiver ansehen.
Grundsätzlich würde ich lieber jsonMap nutzen, um "standardkonforme" Readings zu bekommen (und die dann auch in der setList zu verwenden), als herzugehen und ziemlich spezielle Mappings mit den automatischen Readingnamen vorzunehmen
Ich glaube das geht auch ohne mein userReading, da mir ja das Reading "Mode_hcmode1_value" alle Modis anzeigt (on,off,auto etc..). muss ich nochmal testen und das mapping anpassen.
Zitat von: Beta-User am 04 November 2020, 22:24:56
Zur Vorbereitung könntest du mal die Threads zu ems-esp und dem Fröhlich-Holzscheit-Ding suchen und durchsehen, falls du magst - da sind viele Aspekte in die Richtung schon verarbeitet...
ok, schaue ich mir an.
Hmm, jetzt bin ich zugegebenermaßen etwas ratlos...
Wie sieht denn ein "simples Raumthermostat" aus? (Oder von mir aus auch: Ein Gerät, bei dem man die Warmwassertemperatur einstellen kann?) (Als RAW, bitte)
Aus dem Link zu https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908 (https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908) werde ich nur insoweit schlau, als da auch schon "User-spezifische" settings bereits auf der Ebus-Seite vorhanden sind, oder deute ich das falsch?
Wenn ja: wäre es ein Problem, das eher wieder auf "übliche Standards" zurückzudrehen (so es so etwas gibt...(?))?
Ziel sollte sein, dass ein "Neu-User" möglichst wenig rumfrickeln muss, sondern einfach auf (fast) allen Ebenen mit den "defaults" arbeitet und dann ein funktionierendes Ergebnis hat. Ggf. muss man dann auf der FHEM-Seite noch eventMap setzen, damit es "deutsch" (oder dänisch, französisch...) aussieht, aber auf der funktionalen Ebene würde ich versuchen wollen, eher die "technischen" Begrifflichkeiten zu verwenden...
Zitat von: Beta-User am 05 November 2020, 09:38:21
Aus dem Link zu https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908 (https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908) werde ich nur insoweit schlau, als da auch schon "User-spezifische" settings bereits auf der Ebus-Seite vorhanden sind, oder deute ich das falsch?
Wenn ja: wäre es ein Problem, das eher wieder auf "übliche Standards" zurückzudrehen (so es so etwas gibt...(?))?
Ja meine ist "User-spezifisch" und es ist möglich eine Standard zu nehmen.
Aber von der Standard hcmode.inc bekomme ich nur das Datum und die Außentemperatur. da müssten wir mit john30 zusammen arbeiten das er im git die Dateien anpasst.
Originaldatei sud github von john30:
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/hcmode.inc (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/hcmode.inc)
Ich habe die VR630 und kann halt nur mit meiner hcmode.inc wie in meinem Link die Werte die wir brauchen lesen/setzen.
Zitat von: Beta-User am 05 November 2020, 09:38:21
Ziel sollte sein, dass ein "Neu-User" möglichst wenig rumfrickeln muss, sondern einfach auf (fast) allen Ebenen mit den "defaults" arbeitet und dann ein funktionierendes Ergebnis hat. Ggf. muss man dann auf der FHEM-Seite noch eventMap setzen, damit es "deutsch" (oder dänisch, französisch...) aussieht, aber auf der funktionalen Ebene würde ich versuchen wollen, eher die "technischen" Begrifflichkeiten zu verwenden...
Ja, aber da müssten wir noch andere Vaillant-Nutzer mit ins Boot holen aufgrund der verschiedenen csv´s und inc´s... siehe hier (DE):
https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant)
und hier (EN):
https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/en/vaillant (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/en/vaillant)
Da müssten wir von jeden Vaillantgerat (egal ob Raum- oder Witterungsgeführt) die set/get der Betriebsmodi, Raumtemperatur oder Außentemperatur und der SetRaumtemperatur (desired-temp) raussuchen bzw wissen.
Grübel, ....
Also: wir müssen irgendwo erst mal "einen Nagel einschlagen" und bestimmte Dinge als "given" akzeptieren. Wenn sich "deine" cvs an die "üblichen" (deutschen) Gepflogenheiten hält, ist das m.E. auch ok.
(Ich kenne diese ganzen Mechanismen nicht aus eigener Anschauung und muß daher viel raten, z.B. auch was die Funktionsweise der cvs angeht. Aber allgemein gesagt: je besser der input an john30 ist (insbesondere: konsistent zu allem anderen, was schon da ist), desto eher kann er die Dinge dann auch für alle verfügbar machen, btw..).
Ggf. dann das "de"-template anzupassen und eines für "en" draus zu machen, ist nicht das große Problem, wenn dieser Dualismus schon in den cvs angelegt ist...
ich habe mir dein Problem kurz angesehen, es ist wie auch Beat-User schon festegestellt die Namenskonvention der eigentliche Übeltäter!
w,,SetTempDesiredLow,Absenksollwert setzen,,,,0a,,,temp0,,,
w,,SetHeatingCurve,Heizkurve setzen,,,,0b,,,curve,,,
du hast die Texte in deiner CSV alle mit "Set...." eingeleitet und die gibt es so nicht in den Templates. Ob Read oder Write hängt ja alleine vom Attribut "r,w,wi" ab. Die beste Möglichkeit du gleichst die Namen an die üblichen Calormatic Texte an.
Beispiel:
Hc1HeatCurve
HwcTempDesired
name:E_03_eBus_4xx_devStateIcon_HeatCurve_HwcTemp
filter:TYPE=MQTT2_DEVICE
desc:Format ebus Statusmessages comming from broadcast
par:DEV_ID;name of the device ebus;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
par:BASE_DEV;base topic set in config;{ AttrVal("DEVICE","readingList","") =~ m,ebusd/([^/]*)/, ? $1 : undef }
attr DEVICE setList Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70 ebusd/BASE_DEV/Hc1HeatCurve/set $EVTPART1\
HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0 ebusd/BASE_DEV/HwcTempDesired/set $EVTPART1
attr DEVICE getList Hc1HeatCurve:noArg Hc1HeatCurve_curve_value ebusd/BASE_DEV/Hc1HeatCurve/get \
HwcTempDesired:noArg HwcTempDesired_temp1_value ebusd/BASE_DEV/HwcTempDesired/get
attr DEVICE devStateIcon {my $vC = ReadingsVal($name, "Hc1HeatCurve_curve_value", "10")*10; my $colCur = substr(Color::pahColor(5,10,15,$vC,0),0,6); my $iconCur = 'time_graph@'.$colCur; my $vH = ReadingsVal($name, "HwcTempDesired_temp1_value", "30"); my $colHot = substr(Color::pahColor(20,40,60,$vH,0),0,6); my $iconHot = 'sani_water_hot@'.$colHot; ; "<div style=\"text-align:right\" > " . FW_makeImage("$iconCur",'file_unknown@grey') . "<br> " . FW_makeImage("$iconHot",'sani_water_hot@red') . "</div>"}
attr DEVICE webCmd Hc1HeatCurve_curve_value:HwcTempDesired_temp1_value
attr DEVICE webCmdLabel Heizkurve \
:Warmwasser
attr DEVICE room MQTT2_\DEVICE
attr DEVICE group eBus_Hcurve
attr DEVICE icon message_tendency_steady
attr DEVICE model E_03_eBus_4xx_HeatCurve_HwcTemp
hier ein Auszug aus dem "HeatCurve_HwcTemp" Template und hier wird mit dem Standardnamen "Hc1HeatCurve" und "HwcTempDesired" gerarbeitet. Sie sie dir einfach in der 15.430.csv an. Wenn du die Namen angepasst hast, dann sollten auch zum Großteil die (ebus) Templates funktionieren.
Du kannst aber auch ganz leicht die Templates anpassen, wie du dir leichter tust, nur ich würde auf einheitliche Namen plädieren.
LG
Ich habe mal beispielsweise in den default-csv´s geschaut:
- bei den Raumreglern vr400,450 ist der Betriebsmodus: Hc1OPMode
- bei dem Raumregler 350 ist der Betriebsmodus: OperatingMode
- bei meiner VR630 Heizungsregelung ist der Betriebsmodus: Status02
Mit Betriebsmodus ist on,off,auto etc gemeint...
Es wird also nicht einfach alles einheitlich zu gestalten.
Da müssten wir mal ne Umfrage starten wer welches Vaillant Gerät hat und welche Modi´s mit welcher default-Namensgebung.
Zitat von: Reinhart am 05 November 2020, 14:00:34
ich habe mir dein Problem kurz angesehen, es ist wie auch Beat-User schon festegestellt die Namenskonvention der eigentliche Übeltäter!
Hi Reinhart,
Ich habe damit kein Problem und weiss das man es anpassen kann.
Vergleiche mal bitte die VR630 csv´s und hcmode.inc mit den Raumreglern, da wirst du schon Unterschiede in der Namensgebung sehen wie gerade geschrieben.
Ich habe auch geschrieben, das meine hcmode.inc nur so mit der VR630 spielt (*r,,,,,,"B504",,,,,,,
*w,,,,,,"B505",,,,,,,). Also habe ich schonmal 2 Namen für Hc1OPMode...
Einmal zum lesen und einmal zum schreiben...
Die Namen sind frei vergeben von mir.
ps. es soll nicht böse klingen...
mfg mr_petz
@Reinhart: Das löst aber erst Teil 1 des Problems.
Eigentlich sollten wir die templates dann nochmal so überarbeiten, dass eben nicht "HwcTempDesired" der Reading-Name ist, sondern "desired-temp"; dann sollte das auch mit der Sprachsteuerung klappen ("Helferlein, setze die Warmwassertemperatur auf 55 Grad"). Man muß dann aber eben für verschiedene Baugruppen wirklich getrennte Devices bauen. (Oder man macht eben ein passendes mapping, das ginge auch, ist aber mMn. eher die zweitbeste Lösung...)
Wirf mal einen kurzen Blick in die ems-esp-Thermostat-Templates, v.a. auf den ems-esp_thermostat_simple ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3039 dann wird es evtl. klarer (das ems-esp-Konstrukt ist mMn. 1:1 vergleichbar zu ebus).
Vielleicht noch eine Sache, die ich in der Zwischenzeit gelernt habe: Das Verwalten von Temperaturlisten geht TYPE-übergreifend und sehr komfortabel über weekprofile, sowohl, was die Einrichtung angeht wie auch das Anwenden von Änderungen (z.B. Wechsel von "normalem Tagesprogramm" auf "Ferien" oder "Urlaub", "Kurzarbeit",...; eventuell wäre es den Versuch wert, auch dafür eine Schnittstelle zu basteln (der ganze Mechanismus mit den x dummy-Devices usw. kommt mir reichlich "von Hand" vor). Kommt aber darauf an, was so eine Therme überhaupt wie oft verarbeiten kann (EEPROM-wearout).
Da ich sowas schon für WeekdayTimer gemacht habe, sollte es "möglich" sein...
Weiter würde ich bei der Gelegenheit nochmal anregen, die "get"-Anfragen über ein periodicCmd im MQTT2-Device selbst zu lösen und nicht über ein (händisch zu pflegendes) at. Eigentlich müsste man für jede Baugruppe ja wissen, was man abfragen kann und sollte?
Zitat von: mr_petz am 05 November 2020, 14:04:34
Es wird also nicht einfach alles einheitlich zu gestalten.
Da müssten wir mal ne Umfrage starten wer welches Vaillant Gerät hat und welche Modi´s mit welcher default-Namensgebung.
Würde vorschlagen, dass jemand john30 ins Boot holt und er das entscheidet und ggf. auch auf github vereinheitlicht - eventuell kann ja auch "ein advanced User" eine Art Guideline erstellen (ähnlich https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV bzw. https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings, nur eben auf der ebus-Ebene).
Ansonsten darfst dann eben du entscheiden, wie es gemacht werden soll - "jemand" muß es eben tun (sonst mach ich es, und dann kommt vermutlich was unsinniges raus...).
Auf der FHEM-Seite haben wir übrigens nicht wirklich ein Problem, wir können auch mit unterschiedlichen "Namen" (eigentlich: Topics oder JSON-Keys) für Senden und Empfangen leben, aber wir sollten es dann eben via Readingbenennung/jsonMap so machen, dass es a) einheitlich wird und b) möglichst intuitiv in die allgemeine Landschaft passt...
Klarer?
@Reinhart
hier noch ein Vergleich von 350, 430 und 700 der unterschiedlichen Raumsolltemperatur-Namen:
350 = ActualRoomTempDesired
430 = ActualRoomTempDesiredHc1
700 = z1ActualRoomTempDesired (hier geht es ja nach RaumZonen)
@Beta-User
Also bei mehreren Heizkreisen Hc1,Hc2,Hc3 und Raumthermostaten/zonen müsste man sich was einfallen lassen wie man das mappt oder mehrere templates erstellen...
ich denke so müsste das alexa-mapping aussehen und wäre mit andere Thermostat-Devices konform:
TargetTemperature=desired-temp,minValue=5,maxValue=35,minStep=0.5,nocache=1
CurrentTemperature=measured-temp,nocache=1
TargetHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,cmds=OFF:Hc1Mode+off;HEAT:Hc1Mode+on;ECO:Hc1mode+eco;AUTO:Hc1Mode+auto;COOL:Hc1Mode+low,valid=OFF;HEAT;ECO;AUTO;COOL
CurrentHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,valud=OFF
history:size=1024
die values aufgeschlüsselt als Beispiel:
Zitatdesired-temp = Bsp. setList: Hc1RoomSoll:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebusd/hc/Hc1ActualRoomTempDesired/set $EVTPART1
heatingState = Hc1OPMode --Reading
measured-temp = Hc1RoomTemp --Reading
Hc1Mode (von mir vergeben) = Bsp. setList: Hc1Mode:uzsuDropDown,on,off,auto,eco,low ebusd/hc/Hc1OPMode/set $EVTPART1
schwarz markierte sind die Namen von den *.csv´s und den *.inc die man festlegen könnte....
Das wäre jetzt erstmal so mein Gedankenanstoß wenn ich jetzt nix verwurschtelt habe.
Na ja, wenn es mehrere Heizkreise gibt (die gesondert geregelt werden können sollen), sollten die jeweils in ein eigenes Device, ganz klar - die templates würden sich dann wohl auch nur in der setList und im jsonMapping unterscheiden - ganz so wie bei mehrkanaigen Tasmotas - das sollte kein Problem sein, notfalls könnte man auch für "seltene" eines ohne besondere eigene "Intelligenz" erstellen und die relevanten Angaben vom User abfragen.
Der "Witz" mit "desired-temp" sollte eigentlich sein, dass man es im mapping gar nicht braucht, weil es automatisch richtig gemacht wird - evtl. ausgenommen "ungewöhnliche Wertebereiche". Und alles, was man nicht braucht, sollte man (im Mapping) weglassen - so jedenfalls meine Erfahrung bisher mit dem Thema Sprachsteuerung...
Und sind nicht Hc1OPMode und Hc1Mode identisch (nur eben in Sende- und Empfangsrichtung unterschiedlich benannt) und sollten eigentlich "heatingState" heißen?
Und: könnte man dann auf das Mapping auch an der Stelle nicht ganz verzichten (ggf. müßte man die "Modes" vor dem Versenden in der setList übersetzen (Perl)...)?
Ansonsten sähé das dann Minimalistisch so aus:
TargetHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,cmds=OFF:Mode+off;HEAT:Mode+on;ECO:mode+eco;AUTO:Mode+auto;COOL:Mode+low,valid=OFF;HEAT;ECO;AUTO;COOL
CurrentHeatingCoolingState=heatingState,values=OFF:off;HEAT:on;ECO:eco;AUTO:auto;COOL:low,valud=OFF
history:size=1024
Hoffe, das wird jetzt langsam klarer, in welche Richtung ich da denke?
Zitat von: Beta-User am 05 November 2020, 21:44:15
Na ja, wenn es mehrere Heizkreise gibt (die gesondert geregelt werden können sollen), sollten die jeweils in ein eigenes Device, ganz klar - die templates würden sich dann wohl auch nur in der setList und im jsonMapping unterscheiden - ganz so wie bei mehrkanaigen Tasmotas - das sollte kein Problem sein, notfalls könnte man auch für "seltene" eines ohne besondere eigene "Intelligenz" erstellen und die relevanten Angaben vom User abfragen.
klingt gut.
Zitat von: Beta-User am 05 November 2020, 21:44:15
Der "Witz" mit "desired-temp" sollte eigentlich sein, dass man es im mapping gar nicht braucht, weil es automatisch richtig gemacht wird - evtl. ausgenommen "ungewöhnliche Wertebereiche". Und alles, was man nicht braucht, sollte man (im Mapping) weglassen - so jedenfalls meine Erfahrung bisher mit dem Thema Sprachsteuerung...
wusste ich noch nicht, das das auch ohne mapping geht...
Zitat von: Beta-User am 05 November 2020, 21:44:15
Und sind nicht Hc1OPMode und Hc1Mode identisch (nur eben in Sende- und Empfangsrichtung unterschiedlich benannt) und sollten eigentlich "heatingState" heißen?
Hc1Mode =die setlist vom Hc1OPMode
Hc1OPMode = das Reading
beide können gleich sein (r/w) in der csv, können aber auch unterschiedliche Speicheradressen haben wie in meinem Fall und dadurch 2 Namen w=SetMode r=Mode_hcmode1 haben.
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
*w,,,,,,"B505",,,,,,,
w,,SetMode,Betriebsart,,,,02,,,hcmode3,,,
r,,Mode,Room-Soll/Boiler-Betriebsart/Mixer-Betriebsart/Boilertyp/Temperatur/DayNight,,,,01,,,temp0;hcmode1;IGN:2;mcmode;hctype7;IGN;daynight,,,Zitat von: Beta-User am 05 November 2020, 21:44:15
Hoffe, das wird jetzt langsam klarer, in welche Richtung ich da denke?
ja klingt gut die Richtung
Hmm, irgendwie müssen wir mal konkreter anfangen...
Wenn du (@mr_petz) mir ein RAW-list von dem Ding postest, kann ich mal versuchen, die "Kreise" konkret zu schließen. Die Variablen auf csv/topic-Ebene kann man dann ja später noch tauschen - scheint ja eh' das Grundproblem zu sein, dass man da ggf. was "dynamisiertes" als template braucht. (Das wird Erklärungsbedarf generieren, die User sind es (noch) nicht gewohnt, Fragen der attrTemplate zu beantworten...)
OT zu dem "möglichst ohne"-mapping-Thema: Es gibt dazu ein paar threads, auf die Schnelle ist evtl. der hier aufschlussreich: https://forum.fhem.de/index.php/topic,108080.0.html
OK, ich habe mal ne Nacht darüber geschlafen.
Ich bin zur Erkenntnis gekommen, dass wenn wir wie du sagst "csv/topic-Ebene dynamisch gestalten" ein doch größeres Problem mit den bestehenden ebusd-Nutzern haben.
Wenn die Namen der values in den csv umbenannt/vereinheitlicht werden und ein update der configs (csv) rauskommt , folgt daraus, dass die bestehenden Readings bzw. Set-Befehle wo am Ende noch notifys, doifs oder scripte dran hängen alle nicht mehr greifen und vom User angepasst werden müssten. Oder sehe ich das falsch?
Ich kann mir gut vorstellen, dass da nicht viele erfreut sein werden...
Zitat von: Beta-User am 06 November 2020, 07:22:48
Wenn du (@mr_petz) mir ein RAW-list von dem Ding postest, kann ich mal versuchen, die "Kreise" konkret zu schließen.
Vielleicht sollte da lieber @Reinhart oder ein anderer ebus-Nutzer sein RAW-list posten da er ja die default Sachen drin hat und bei mir ist eher vieles Benutzerdefiniert.
Oder sag konkreter was du wissen/erklärt haben möchtest.
Für den ebusd mqtt2 gibt es ja auch schon templates von euch:
https://wiki.fhem.de/wiki/EBUS-MQTT2#Anwendung_der_Templates (https://wiki.fhem.de/wiki/EBUS-MQTT2#Anwendung_der_Templates)
wie es auch hier im Thread zu lesen ist.
Kannst du da nicht auch schon was raus lesen um die Kreise zu schließen oder willst du jetzt ausschließlich meinen Fall zur Grundlage nehmen?
Ich mache hier aber natürlich weiter mit...
Spricht irgendwas dagegen, dass du einfach ein RAW von dem Device postest, das du auszugsweise bereits hier gepostet hattest?
Wie gesagt: das ganze ggf. durch Abfragen beim User konfigurierbar zu machen wäre nicht das Problem, wir sollten aber erst den POC fertig machen, und dazu brauche man halt einen Prototypen, selbst, wenn der unter manchen Gesichtspunkten nicht optimal ist...
OK. Ich kann erst heute Abend ein RAW posten. bin noch @work...
RAW
defmod MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd alexaName Heizung
attr MQTT2_ebusd alias Heizung
attr MQTT2_ebusd autocreate 1
attr MQTT2_ebusd bridgeRegexp (ebus.)[^/]*/(bai|broadcast)/.*:.* "$1_bai"\
(ebus.)[^/]*/([\d]+)/.*:.* "$1_$2"\
(ebus.)[^/]*[/][^b][a-zA-Z]+[/].*:.* "$1"
attr MQTT2_ebusd devStateIcon 1.true:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd devStateStyle style="text-align:right"
attr MQTT2_ebusd disable 0
attr MQTT2_ebusd event-on-change-reading .*
attr MQTT2_ebusd genericDeviceType thermostat
attr MQTT2_ebusd homebridgeMapping CurrentTemperature=Status16_temp_value,nocache=1\
TargetHeatingCoolingState=heatingState,values=OFF:OFF;;HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;COOL:OFF,cmds=OFF:Heizmodus+off;;HEAT:Heizmodus+on;;ECO:Heizmodus+eco;;AUTO:Heizmodus+auto;;COOL:Heizmodus+off,valid=OFF;;HEAT;;ECO;;AUTO;;COOL\
CurrentHeatingCoolingState=heatingState,values=HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;OFF:OFF;;COOL:OFF,valud=OFF\
TargetTemperature=Status_2_value,minValue=0,maxValue=28,minStep=0.5,nocache=1\
StatusActive=signal,valueOn=true,valueOff=false\
history:size=1024
attr MQTT2_ebusd icon sani_boiler_temp
attr MQTT2_ebusd jsonMap Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
attr MQTT2_ebusd model E_00_eBus_daemon_splitter
attr MQTT2_ebusd readingList ebusd/global/uptime:.* uptime\
ebusd/broadcast/datetime:.* { json2nameValue($EVENT, 'datetime_', $JSONMAP) }\
ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\.23/:.* { json2nameValue($EVENT, 'scan.23_', $JSONMAP) }\
ebusd/scan\.25/:.* { json2nameValue($EVENT, 'scan.25_', $JSONMAP) }\
ebusd/scan\.26/:.* { json2nameValue($EVENT, 'scan.26_', $JSONMAP) }\
ebusd/scan\.35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\.35/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/scan\.44/:.* { json2nameValue($EVENT, 'scan.44_', $JSONMAP) }\
ebusd/scan\.50/:.* { json2nameValue($EVENT, 'scan.50_', $JSONMAP) }\
ebusd/scan\.51/:.* { json2nameValue($EVENT, 'scan.51_', $JSONMAP) }\
ebusd/scan\.84/:.* { json2nameValue($EVENT, 'scan.84_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/global/updatecheck:.* updatecheck\
ebusd/global/signal:.* signal\
ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }\
ebusd/hc/Params:.* { json2nameValue($EVENT, 'Params_', $JSONMAP) }\
ebusd/hc/Status:.* { json2nameValue($EVENT, 'Status_', $JSONMAP) }\
ebusd/hc/Status16:.* { json2nameValue($EVENT, 'Status16_', $JSONMAP) }\
ebusd/ui/OutsideTempOffset:.* { json2nameValue($EVENT, 'OutsideTempOffset_', $JSONMAP) }\
ebusd/hc/Params/get:.* get\
ebusd/ui/OutsideTempOffset/get:.* get
attr MQTT2_ebusd room Heizung
attr MQTT2_ebusd setList getKnown:noArg ebusd/list onlyknown\
getAll:noArg ebusd/list\
Params ebusd/hc/Params/get\
OTempO ebusd/ui/OutsideTempOffset/get\
Heizmodus:uzsuDropDown,on,off,auto,eco,low ebusd/hc/SetMode/set $EVTPART1\
Heizkurve:uzsuDropDown,0.20,0.50,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70,1.80,1.90,2.00 ebusd/hc/SetHeatingCurve/set $EVTPART1\
ATKorrektur:uzsuDropDown,-3.00,-2.50,-2.00,-1.50,-1.00,-0.50,0.00,0.50,1.00,1.50,2.00,2.50,3.00 ebusd/ui/OutsideTempOffset/set $EVTPART1\
RoomTemp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebusd/hc/SetTempDesired/set $EVTPART1\
MinVLTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetFlowTempMin/set $EVTPART1\
MaxVLTemp:uzsuDropDown,60,61,62,63,64,65,66,67,68,69,70 ebusd/hc/SetFlowTempMax/set $EVTPART1\
AussenAusTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetShutdownTemp/set $EVTPART1\
AbsenkTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetTempDesiredLow/set $EVTPART1\
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
attr MQTT2_ebusd stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd userReadings tempState { if (ReadingsVal($name,"signal","true") eq "true"){"-25"}},\
tempState2 { if (ReadingsVal($name,"signal","true") eq "true"){"0"}},\
heatingState { if (ReadingsVal($name,"Mode_hcmode1_value","-") eq "off"){"OFF"} elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "on"){"HEAT"} elsif (ReadingsVal($name,"Mode_hcmode1_value","auto") eq "auto"){"AUTO"} elsif (ReadingsVal($name,"Mode_hcmode1_value","-") eq "low"){"COOL"} else {"ECO"}},\
formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
attr MQTT2_ebusd verbose 0
setstate MQTT2_ebusd Status: \
1:true\
Signal: \
2:true\
<br>Uptime: 0 005 13:51
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_daynight_value day
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_hcmode1_value auto
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_hctype7_value hc789
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_mcmode_value off
setstate MQTT2_ebusd 2020-11-06 19:08:52 Mode_temp0_value 26
setstate MQTT2_ebusd 2020-11-06 19:04:42 OutsideTempOffset_temp_value -2.00
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_0_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_0_value 26
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_1_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_1_value 16
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_2_name curve
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_2_value 1.20
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_3_name hctype7
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_3_value hc789
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_4_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_4_value 19
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_5_name minutes0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_5_value 0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_6_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_6_value 20
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_7_name temp0
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_7_value 69
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_8_name hours12
setstate MQTT2_ebusd 2020-11-06 19:04:42 Params_8_value 0
setstate MQTT2_ebusd 2020-11-06 19:08:18 Status16_temp_value 6.00
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_0_name temp0
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_0_value 68
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_1_name onoff
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_1_value off
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_2_name temp
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_2_value 48.81
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_3_name temp0
setstate MQTT2_ebusd 2020-11-06 19:08:52 Status_3_value 26
setstate MQTT2_ebusd 2020-04-23 19:10:39 ValvePosition 0
setstate MQTT2_ebusd 2020-04-10 16:23:10 associatedWith MQTT2_ebusd
setstate MQTT2_ebusd 2020-11-06 19:08:17 datetime_date_value 06.11.2020
setstate MQTT2_ebusd 2020-11-06 19:08:17 datetime_outsidetemp_value 6.000
setstate MQTT2_ebusd 2020-11-06 19:08:17 datetime_time_value 19:08:01
setstate MQTT2_ebusd 2020-04-23 19:10:39 desired-temp auto
setstate MQTT2_ebusd 2020-11-06 19:08:48 formatedUptime 0 005 13:51
setstate MQTT2_ebusd 2020-11-06 19:04:37 get
setstate MQTT2_ebusd 2020-11-06 19:08:52 heatingState AUTO
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_counter_value 005395
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_prefix_value 21
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_product_value 0020040079
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_suffix_value N2
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_supplier_value 0907
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_week_value 44
setstate MQTT2_ebusd 2020-07-17 09:04:06 id_year_value 11
setstate MQTT2_ebusd 2020-04-23 19:10:39 measured-temp 21
setstate MQTT2_ebusd 2020-11-01 09:13:47 running true
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_HW_value 6201
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_ID_value UI
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:03:49 scan.15_SW_value 0231
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:03:57 scan.23_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:03:58 scan.25_SW_value 0306
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_HW_value 6301
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_ID_value VR630
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_MF_value Vaillant
setstate MQTT2_ebusd 2020-08-10 10:26:12 scan.26_SW_value 0306
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_HW_value 6201
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_ID_value RC C
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_MF_value Vaillant
setstate MQTT2_ebusd 2020-08-10 10:26:42 scan.35_SW_value 0501
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:04:29 scan.44_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:04:35 scan.50_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:04:36 scan.51_SW_value 0306
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_HW_value 6301
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_ID_value VR630
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_MF_value Vaillant
setstate MQTT2_ebusd 2020-07-17 09:05:12 scan.84_SW_value 0306
setstate MQTT2_ebusd 2020-11-01 09:13:47 signal true
setstate MQTT2_ebusd 2020-11-06 19:04:37 state OTempO
setstate MQTT2_ebusd 2020-11-06 19:08:52 tempState -25
setstate MQTT2_ebusd 2020-11-06 19:08:52 tempState2 0
setstate MQTT2_ebusd 2020-11-01 09:13:47 updatecheck "revision v3.4 available, broadcast.csv: newer version available, vaillant/15.ui.csv: different version available, vaillant/23.vr630.cc.csv: newer version available, vaillant/25.vr630.hwc.csv: different version available, vaillant/26.vr630.hc.csv: different version available, vaillant/50.vr630.mc.csv: newer version available, vaillant/51.vr630.mc.3.csv: newer version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: different version available, vaillant/hwcmode.inc: different version available"
setstate MQTT2_ebusd 2020-11-06 19:08:48 uptime 481896
setstate MQTT2_ebusd 2020-11-01 09:13:46 version "ebusd 3.4.v3.3-51-g57eae05"
Umbenanntes Testdevice:
defmod MQTT2_ebusd_test MQTT2_DEVICE ebusd
attr MQTT2_ebusd_test IODev ebusMQTT
attr MQTT2_ebusd_test alexaName Heizung
attr MQTT2_ebusd_test alias Heizung
attr MQTT2_ebusd_test autocreate 1
attr MQTT2_ebusd_test devStateIcon 1.true:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd_test devStateStyle style="text-align:right"
attr MQTT2_ebusd_test disable 0
attr MQTT2_ebusd_test event-on-change-reading .*
attr MQTT2_ebusd_test genericDeviceType thermostat
attr MQTT2_ebusd_test homebridgeMapping StatusActive=signal,valueOn=true,valueOff=false\
history:size=1024
attr MQTT2_ebusd_test icon sani_boiler_temp
attr MQTT2_ebusd_test jsonMap Status16_temp_value:measured-temp Status_2_value:desired-temp Mode_hcmode1_value:heatingState Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
attr MQTT2_ebusd_test model E_00_eBus_daemon_splitter
attr MQTT2_ebusd_test readingList ebusd/global/uptime:.* uptime\
ebusd/broadcast/datetime:.* { json2nameValue($EVENT, 'datetime_', $JSONMAP) }\
ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\.23/:.* { json2nameValue($EVENT, 'scan.23_', $JSONMAP) }\
ebusd/scan\.25/:.* { json2nameValue($EVENT, 'scan.25_', $JSONMAP) }\
ebusd/scan\.26/:.* { json2nameValue($EVENT, 'scan.26_', $JSONMAP) }\
ebusd/scan\.35/:.* { json2nameValue($EVENT, 'scan.35_', $JSONMAP) }\
ebusd/scan\.35/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/scan\.44/:.* { json2nameValue($EVENT, 'scan.44_', $JSONMAP) }\
ebusd/scan\.50/:.* { json2nameValue($EVENT, 'scan.50_', $JSONMAP) }\
ebusd/scan\.51/:.* { json2nameValue($EVENT, 'scan.51_', $JSONMAP) }\
ebusd/scan\.84/:.* { json2nameValue($EVENT, 'scan.84_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/global/updatecheck:.* updatecheck\
ebusd/global/signal:.* signal\
ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }\
ebusd/hc/Params:.* { json2nameValue($EVENT, 'Params_', $JSONMAP) }\
ebusd/hc/Status:.* { json2nameValue($EVENT, 'Status_', $JSONMAP) }\
ebusd/hc/Status16:.* { json2nameValue($EVENT, 'Status16_', $JSONMAP) }\
ebusd/ui/OutsideTempOffset:.* { json2nameValue($EVENT, 'OutsideTempOffset_', $JSONMAP) }\
ebusd/hc/Params/get:.* get\
ebusd/ui/OutsideTempOffset/get:.* get
attr MQTT2_ebusd_test room Heizung
attr MQTT2_ebusd_test setList getKnown:noArg ebusd/list onlyknown\
getAll:noArg ebusd/list\
Params ebusd/hc/Params/get\
OTempO ebusd/ui/OutsideTempOffset/get\
heatingState:uzsuDropDown,ON,OFF,AUTO,ECO,LOW ebusd/hc/SetMode/set $EVTPART1\
Heizkurve:uzsuDropDown,0.20,0.50,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70,1.80,1.90,2.00 ebusd/hc/SetHeatingCurve/set $EVTPART1\
ATKorrektur:uzsuDropDown,-3.00,-2.50,-2.00,-1.50,-1.00,-0.50,0.00,0.50,1.00,1.50,2.00,2.50,3.00 ebusd/ui/OutsideTempOffset/set $EVTPART1\
RoomTemp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebusd/hc/SetTempDesired/set $EVTPART1\
MinVLTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetFlowTempMin/set $EVTPART1\
MaxVLTemp:uzsuDropDown,60,61,62,63,64,65,66,67,68,69,70 ebusd/hc/SetFlowTempMax/set $EVTPART1\
AussenAusTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetShutdownTemp/set $EVTPART1\
AbsenkTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetTempDesiredLow/set $EVTPART1\
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
attr MQTT2_ebusd_test stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd_test userReadings tempState:signal.* { if (ReadingsVal($name,"signal","true") eq "true"){"-25"}},\
tempState2:signal.* { if (ReadingsVal($name,"signal","true") eq "true"){"0"}},\
formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
attr MQTT2_ebusd_test verbose 0
Hoffe, das klappt so, Teile sind einfach geraten und die Zuordnungen dürfen gerne verbessert werden...
Die bridgeRegexp habe ich weggelassen, die ist ja an dem anderen schon vorhanden. Aber bei der Gelegenheit eine Frage: Warum hast du das so geändert, dass nicht jede Baugruppe ihr eigenes Device erhält?
Meine Gedanken damals bei der Entwicklung war, dass es tendenziell sinnvoll ist, "handhabbare" Teile zu haben, wenn sie funktional für was bestimmtes zuständig sind. Falls diese Überlegung in der Praxis nicht trägt, können wir gerne versuchen, das entsprechend anzupassen, aber gerade dann, wenn man unterschiedliche Teilaspekte "betrachten" will (und z.B. per Sprachsteuerung ansprechen), ist es m.E. einfacher, wenn man aufspaltet.
Zitat von: Beta-User am 07 November 2020, 08:43:41
Warum hast du das so geändert, dass nicht jede Baugruppe ihr eigenes Device erhält?
Was meinst du mit Baugruppen?
Und soll ich dein Device jetzt einfach einfügen? Stört das nicht wenn Heizung als alias 2 mal in fhem angelegt wird? Oder soll ich mein Heizungsdevice daweile disablen? Auch schon wegen Alexa-APP...
Will nur sicher gehen.
Edit:
Ich weiss jetzt glaube was du meinst mit Baugruppen (denke ich).
die hc, ui usw.. ?
Die gibt es bei mir auch als seperate Devices, da habe ich mir nur die Readinglists geholt die ich auch nur verwende und damit Zentralisiert.
alias kannst du löschen, ansonsten sollte sich das nicht in die Quere kommen.
Und "Baugruppe" ist genau das, was jeweils einen eigenen "Topic"-Abschnitt hat - meine Vermutung ist, dass sich dahinter eben jeweils eine Art logischer "Funktionseinheit" oder so verbirgt - aber wie gesagt, ich habe das nur vor langer Zeit mal remote an einem "fremden" Bus so "festgelegt" und bin für Verbesserungsvorschläge offen, auch, was das "wording" angeht...
Start
[07/11/2020, 18:25:12] [FHEM] MQTT2_ebusd_test is thermostat
[07/11/2020, 18:25:12] [FHEM] MQTT2_ebusd_test has
[07/11/2020, 18:25:12] [FHEM] TargetTemperature [desired-temp]
[07/11/2020, 18:25:12] [FHEM] CurrentTemperature [measured-temp]
[07/11/2020, 18:25:12] [FHEM] CurrentHeatingCoolingState [undefined]
[07/11/2020, 18:25:12] [FHEM] StatusActive [signal]
[07/11/2020, 18:25:12] [FHEM] history [undefined]
2020-11-07 18:25:12 caching: MQTT2_ebusd_test-desired-temp: 47.19
2020-11-07 18:25:12 caching: MQTT2_ebusd_test-measured-temp: 7.25
[07/11/2020, 19:01:03] [FHEM] caching: TargetTemperature: 54.25 (as string; from '54.25')
2020-11-07 19:01:03 caching: MQTT2_ebusd_test-desired-temp: 54.25
[07/11/2020, 19:01:03] [FHEM] caching: TargetTemperature: 28 (as number; from '54.25')
AppScreenshot:
:) 2 von 3, wenn ich das richtig deute. Das ist doch schon mal was ;) ...
measured-temp müßte man ja eh' nur abfragen können, desired-temp dann setzen und auslesen? Also: Funktioniert da der "Kreis" und werden die richtigen (Hex-) Adressen angesprochen/abgefragt?
Was CurrentHeatingCoolingState und StatusActive angeht:
Gibt es dafür "default" ReadingNamen?
Und sind die Setz-Werte für CurrentHeatingCoolingState irgendwie normiert? Soll/kann man das "übersetzen"?...?
(Mit size habe ich keine Ahnung, was das für eine Bedeutung hat; ist einfach übernommen aus dem was da war (wie signal)).
Grundsätzlich: Ist denn die Vorgehensweise klarer jetzt, nachdem das mit den ersten beiden zu funktionieren scheint?
Aus https://wiki.fhem.de/wiki/Homebridge_einrichten (https://wiki.fhem.de/wiki/Homebridge_einrichten)
ZitatÜber eine history Characteristic lässt sich für bestimmte Service-Typen eine Eve-Kompatible history aktivieren:
Die Angabe ist nur relevant wenn man die EVE-App nutzt.
Zitat von: Beta-User am 07 November 2020, 19:09:40
Was CurrentHeatingCoolingState und StatusActive angeht:
Gibt es dafür "default" ReadingNamen?
Und sind die Setz-Werte für CurrentHeatingCoolingState irgendwie normiert? Soll/kann man das "übersetzen"?...?
Hatte ich schon was dazu geschrieben.
bei den Raumreglern vr400,450 ist der Betriebsmodus: Hc1OPMode
bei dem Raumregler 350 ist der Betriebsmodus: OperatingMode
bei meiner VR630 Heizungsregelung ist der Betriebsmodus: Status02_hwcmode
oder Mode_hcmode1(nur bei mir)
die values sollten gleich sein denke ich:
Bei mir kommts klein: off,on,auto,eco,low
Zitat von: Beta-User am 07 November 2020, 19:09:40
Grundsätzlich: Ist denn die Vorgehensweise klarer jetzt, nachdem das mit den ersten beiden zu funktionieren scheint?
Ich kann halt nicht die Temperatur einstellen, weil der
Raumtemperatur geht nicht zu setzen, weil der Readingname durch mein Benutzerdef. Sachen jetzt nicht stimmt.
Es müsste eigendlich 26 stehen. Steht aber 28.
Edit:geht nur so zu setzen:
statt
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1so
desired-temp:uzsuDropDown,18,19,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
@TomLee: Danke für den Einwurf, da war doch noch was...
https://wiki.fhem.de/wiki/Alexa_und_Mappings (https://wiki.fhem.de/wiki/Alexa_und_Mappings)
Es scheint demnach für "thermostate" noch kein "generelles mapping" für den "allgemeinen Betriebsmodus" zu geben. (@mr_petz: Das Umbenennen im MQTT2_DEVICE ist erst Stufe 2, das dockt dann "nur" daran an, was insbesondere das alexa-mapping gerne hätte - wie bei desired-temp)
MAn. sollte man dazu eine kurze Anfrage im Sprachsteuerungsbereich starten, insbesondere Richtung justme1968. Kann das einer von übernehmen? Ist nicht eben meine Kernkompetenz...
(Den Rest schaue ich mir später an, für heute ist erst mal Schluß).
Zitat von: Beta-User am 07 November 2020, 20:36:44
MAn. sollte man dazu eine kurze Anfrage im Sprachsteuerungsbereich starten, insbesondere Richtung justme1968. Kann das einer von übernehmen? Ist nicht eben meine Kernkompetenz...
Hatte ich schonmal erfolglos gemacht wegen den Betriebsmodis:
https://forum.fhem.de/index.php/topic,110531.0.html (https://forum.fhem.de/index.php/topic,110531.0.html)
Zitat@TomLee: Danke für den Einwurf, da war doch noch was...
https://wiki.fhem.de/wiki/Alexa_und_Mappings
Komm hier nur halb mit,
homebridgeMapping und ich werden wsl. nie Freunde ;D
Meine Heizung ist witterungsgeführt und ich hab keine Raumregelung,
ich hab bisher keinen Bedarf die Heizung per Sprache zu steuern.
OK, die Warmwassertemperatur abfragen hab ich mir eingerichtet nutz ich aber wirklich selten / gar nicht.
Und für die Aussentemperatur abzufragen hab ich draussen einen DS18B20 (1-Wire).
Darum lese ich hier nur interessiert mit :)
Falls die Frage auf alexaMapping zielt und du nicht weißt das einzuordnen, das ist nur für den Custom-Skill relevant (den nutzt mMn. fast keiner mehr).
Hier gehts aber ausschließlich um den Smart-Home-Skill und da mappt man mit
homebridgeMapping.
Zitat von: TomLee am 07 November 2020, 21:34:19
Komm hier nur halb mit, homebridgeMapping und ich werden wsl. nie Freunde ;D
...was diese mappings angeht, stehe ich auch gefühlt völlig im Wald... Wenn man im Wiki nach homebridgeMapping stöbert, landet man auch wieder auf den alexa-Seiten, oder?
Na jedenfalls habe ich im Wiki bisher nichts vernünftiges gefunden, was für diesen Fall hier zu passen scheint.
Zitat von: mr_petz am 07 November 2020, 20:47:20
Hatte ich schonmal erfolglos gemacht wegen den Betriebsmodis:
https://forum.fhem.de/index.php/topic,110531.0.html (https://forum.fhem.de/index.php/topic,110531.0.html)
Aus dem Link von mr_petz und dem, auf das justme1968 verwiesen hat (https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-property-schemas.html#thermostat-mode (https://developer.amazon.com/en-US/docs/alexa/device-apis/alexa-property-schemas.html#thermostat-mode)), meine ich, dass das Reading "thermostatMode" heißen sollte. Also bitte mal testweise in dem Vorschlag von hier
Zitat von: Beta-User am 07 November 2020, 08:43:41
Umbenanntes Testdevice: [...]
heatingState durch thermostatMode ersetzen.
Bitte ggf. checken, ob das Device auch auf der Ebene der betreffenden Sprachsteuerung dann wieder neu initialisiert worden ist (will sagen: kann sein, dass man da die Erkennung neu starten muss oder den Dienst).
(Falls das nicht klappt, wäre ein weiterer Test mit "thermostat-mode" nett, aber ich würde tippen, dass "the winner" "thermostatMode" heißt).
Zitat von: Beta-User am 09 November 2020, 10:19:19
Vorschlag von hierheatingState durch thermostatMode ersetzen.
gemacht
Zitat
Bitte ggf. checken, ob das Device auch auf der Ebene der betreffenden Sprachsteuerung dann wieder neu initialisiert worden ist (will sagen: kann sein, dass man da die Erkennung neu starten muss oder den Dienst).
CurrentHeatingCoolingState [undefined]
Zitat
(Falls das nicht klappt, wäre ein weiterer Test mit "thermostat-mode" nett, aber ich würde tippen, dass "the winner" "thermostatMode" heißt).
CurrentHeatingCoolingState [undefined]
Hmm, schade eigentlich...
Da das aber die "quais-offizielle" Benennung für diesen Datenpunkt zu sein scheint, würde ich das Reading jetzt trotzdem so benennen wollen, vielleicht kann man dann ja die weiteren Mappings weglassen? Ansonsten machen wir die halt auch noch dazu, die Devise war ja "nur", wegzulassen, was nicht erforderlich ist.
Wäre nett, wenn du justme1968 in dem Thread noch den Hinweis (mit Link hierher) gibts, dass wir das in diese Richtung vorhaben, erfahrungsgemäß wird er sich dann melden, wenn wir hier in die falsche Richtung laufen... Das gleiche Problem stellt sich btw. auch im ems-esp-Thread, von daher wäre mir an einer einheitlichen Lösung gelegen.
Bezugnehmend auf die Antwort von justme1968 aus dem anderen Thread: bitte nochmal testen mit "mode"...
Zitat von: Beta-User am 10 November 2020, 16:33:29
bitte nochmal testen mit "mode"...
leider auch
[10/11/2020, 20:16:18] [FHEM] CurrentHeatingCoolingState [undefined]
Na ja, wie dem auch sei, dann nennen wir das Kind jetzt trotzdem "mode".
Jetzt wäre also die Frage, mit welcher "Baugruppe" wir denn beginnen wollen...?
Zitat von: Beta-User am 05 November 2020, 14:27:08
@Reinhart:
[...]
Vielleicht noch eine Sache, [...]: Das Verwalten von Temperaturlisten geht TYPE-übergreifend und sehr komfortabel über weekprofile, sowohl, was die Einrichtung angeht wie auch das Anwenden von Änderungen (z.B. Wechsel von "normalem Tagesprogramm" auf "Ferien" oder "Urlaub", "Kurzarbeit",...; eventuell wäre es den Versuch wert, auch dafür eine Schnittstelle zu basteln (der ganze Mechanismus mit den x dummy-Devices usw. kommt mir reichlich "von Hand" vor). Kommt aber darauf an, was so eine Therme überhaupt wie oft verarbeiten kann (EEPROM-wearout).
Da [...] sollte es "möglich" sein...
Zwischenzeitlich habe ich noch etwas mit Code gespielt (https://forum.fhem.de/index.php/topic,97430.msg1100788.html#msg1100788), um zwischen CUL_HM-tempList- Formaten und weekprofile Daten hin- und herzuschaufeln. Falls da also Interesse besteht, sowas wie eine Schnittstelle zwischen den Welten zu basteln: feel free. Sollten wir aber ggf. in einen separaten Thread auslagern.
Benötigen würde ich Infos, wie die Readings nach den get-Anfragen konkret aussehen, um sie ggf. nach weekprofile transferieren zu können. Das Sendeformat ist ja in der template-file eigentlich gut zu erkennen, aber auch da wäre "etwas Theorie" ggf. hilfreich...
Vorab wäre dann natürlich noch gut zu wissen, ob die Regelung es eigentlich verträgt, wenn man da immer mal wieder was umstellt. Es dürfte User geben, die ggf. Probleme haben, passende Event-Handler zu bauen und dann unbeabsichtigt sehr häufig umschalten; sowas sollte möglichst nicht dazu führen, dass die Heizung dann vorzeitig aussteigt...
(EDIT: link zu dem CUL_HM-Code ergänzt)
Zitat von: Beta-User am 12 November 2020, 12:20:44
Jetzt wäre also die Frage, mit welcher "Baugruppe" wir denn beginnen wollen...?
für die 630/620 können wir mit der hc anfangen.
Und für mich zum Verständnis, wie im Detail willst du beginnen?
Na ja, ein RAW-list von so einem 630 (einschl. Readings), wie es die bridgeRegexp erzeugt, wäre erst mal ein Startpunkt...
Das ist ja das, was ein "Einsteiger" in das Thema zu sehen bekommt und dann weiter konfigurieren bekommt.
Nehmen wir mal das Template zur Vorlage.
Denke da kannst du was mit anfangen.
###############
#ebusd
#
#ebus daemon device
name:eBus_daemon_splitter
filter:TYPE=MQTT2_DEVICE
desc:Device containing all status messages from the ebus daemon itself<br>NOTE: acts also as a bridge device to split up the hardware on the bus into different mqtt2_devices<br>NOTE:<br>- for use with MQTT2_CLIENT use a copy of the Device with the same clientId than the IO, delete original's readingList after applying the template!<br>- this might change the devices CID
order:E_01a
par:DEVTYPE;Internal TYPE of the device; { InternalVal("DEVICE","TYPE",undef)}
par:DEV_ID;base topic set ebus;{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:?(ebus[a-zA-Z])[^/]*[/].*:, ? $1 : "ebusd" }
par:ICON;ICON as set, defaults to sani_boiler_temp;{ AttrVal("DEVICE","icon","sani_boiler_temp") }
{ Svn_GetFile("contrib/AttrTemplate/99_attrTmqtt2_ebus_Utils.pm", "FHEM/99_attrTmqtt2_ebus_Utils.pm", sub(){ CommandReload(undef, "99_attrTmqtt2_ebus_Utils") }) }
{ Svn_GetFile("contrib/AttrTemplate/mqtt2.ebus.template", "FHEM/lib/AttrTemplate/mqtt2.ebus.template", sub(){ AttrTemplate_Initialize() }) }
attr DEVICE icon ICON
modify DEVICE DEV_ID
attr DEVICE autocreate 1
attr DEVICE bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr DEVICE userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
attr DEVICE stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr DEVICE devStateIcon 1.true:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
attr DEVICE setList getKnown:noArg DEV_ID/list onlyknown\
getAll:noArg DEV_ID/list
set DEVICE getKnown
attr DEVICE comment NOTE: additional templates and code have been downloaded from svn (contrib).
farewell:template has been applied successfully. <br>NOTE: additional templates and code have been downloaded from svn (contrib). <br>To configure further parts of your ebus ecosystem, have a look at these templates and the <a href=https://wiki.fhem.de/wiki/EBUS-MQTT2">Wiki</a>.
attr DEVICE model eBus_daemon_splitter
setreading DEVICE attrTemplateVersion 20200522 or prior
Hier sind ja die bridgeRegexp (hc,mc,hwc....usw.) alle drin:
attr DEVICE bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
Das habe ich auch als Standard genommen für meine 630.
Hier ist die originale hcmode.inc für die 630, wo Readings herkommen.
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
r,,DateTime,Datum Uhrzeit,,,,00,,,dcfstate;btime;bdate;temp2,,,
r,,Status16,Aussentemperatur,,,,16,,,temp,,,
# HC Betriebsart2,,,,,,,,,,,,,
*r,,,,,,"B511",,,,,,,
*uw,,,,,,"B510",,,,,,,
uw,,SetMode,Betriebsart,,,,00,,,hcmode,,,,flowtempdesired,,temp1,,,,hwctempdesired,,temp1,,,,hwcflowtempdesired,,temp0,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2,,,,
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
r,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTEMP/Maximaltemperatur/ReglerCurrentTemp,,,,02,,,hwcmode;temp0;temp1;temp0;temp1,,,
r,,Status,Status,,,,03,,,temp;press;press;hcmode2;HEX,,,
*uw,,,,,,"B512",,,,,,,
uw,,StatusCirPump,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,
Theoretisch sollte der Status02 die Betriebsmodi (on,off,auto,eco,low) im Reading Status02_1_value liefern. Mehr kann ich dazu nicht sagen.
Bei mir ging das aber nicht, deswegen habe ich eine eigene hcmode.inc verfasst.
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
*w,,,,,,"B505",,,,,,,
r,,DateTime,Datum Uhrzeit,,,,00,,,dcfstate;btime;bdate;temp2,,,
r,,Mode,Room-Soll/Boiler-Betriebsart/Mixer-Betriebsart/Boilertyp/Temperatur/DayNight,,,,01,,,temp0;hcmode1;IGN:2;mcmode;hctype7;IGN;daynight,,,
r,,Status16,Aussentemperatur,,,,16,,,temp,,,
r,,Status,VL-Soll/Status/VL-Ist/Room-Soll,,,,0D,,,temp0;onoff;temp;temp0,,,
r,,Params,Raumsollwert/Absenksollwert/Heizkurve/HK1-Typ/AT-Abschaltgrenze/Pumpensperrzeit/HK1-VL-MinTemp/HK1-VL-MaxTemp/Max. Voraufheizung,,,,09,,,temp0;temp0;curve;hctype7;temp0;minutes0;temp0;temp0;hours12,,,
#r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp;temp1;temp2;temp1;temp1;pumpstate,,,
r,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTEMP/Maximaltemperatur/ReglerCurrentTemp,,,,02,,,HEX;HEX;HEX;HEX;HEX;HEX;onoff,,,
w,,SetTempDesired,Solltemperatur setzen,,,,01,,,temp0,,,
w,,SetMode,Betriebsart,,,,02,,,hcmode3,,,
w,,SetFloorPavingDryingDay,Estrichtrocknungstag setzen,,,,03,,,days,,,
w,,SetFloorPavingDryingTemp,Estrichtrocknungstemperatur setzen,,,,04,,,temp0,,,
w,,party,Quick - Party,,,,05,,,onoff,,,
w,,load,Quick - WW Speicherladung,,,,06,,,onoff,,,
w,,save,Quick - Sparen bis,,,,07,,,TTH,,,
w,,SetType,Boilertyp setzen,,,,08,,,hctype,,,
w,,SetTempDesiredLow,Absenksollwert setzen,,,,0a,,,temp0,,,
w,,SetHeatingCurve,Heizkurve setzen,,,,0b,,,curve,,,
w,,SetShutdownTemp,Aussentemp. Abschaltgrenze setzen,,,,0c,,,temp0,,,
w,,SetPumpIdlePeriod,Pumpensperrzeit setzen,,,,0d,,,minutes0,,,
w,,SetFlowTempMin,Minimalen Vorlaufsollwert setzen,,,,0e,,,temp0,,,
w,,SetFlowTempMax,Maximalen Vorlaufsollwert setzen,,,,0f,,,temp0,,,
w,,SetMaxPreHeating,Max. Voraufheizung setzen,,,,10,,,hours12,,,
Hier wird im Reading Mode_02_value die Betriebsmodi gelesen und im SetMode gesetzt.
im Reading Mode_02_value wird die Raumtemperatur gelesen und mit SetTempDesired gesetzt.
Es werden wie hier im Beispiel:
r,,Mode,Room-Soll/Boiler-Betriebsart/Mixer-Betriebsart/Boilertyp/Temperatur/DayNight,,,,01,,,temp0;hcmode1;IGN:2;mcmode;hctype7;IGN;daynight,,,
10 Readings mit Namen: Mode_0_name ~ Mode_4_name (tem0,hcmode1...usw) und Mode_0_value ~ Mode_4_value (on,off,25...etc) erzeugt.
Und das wäre bei mir die ReadingList dafür:
ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }
Ich hoffe ich konnte da ein wenig Aufschluss geben.
ps.:Wie ich schon einmal sagte, man sollte andere ebusd Nutzer mit ins Boot holen.
Die verschiedenen Geräte (z.B.:350, 430, 700) mit deren Readings kenne ich alle auch nicht.
Weiss sonst auch nicht wie ich weiter helfen kann. ???
Ähm, komme grade noch nicht mit. Das eBus_daemon_splitter-Template hatte ich damals mal so konzipiert, das scheint ja unverändert zu sein, und mir ist auch einigermaßen präsent, welche Devices es in etwa bei einer "klassischen Heizung" macht. Das "Zentraldevice" ist dann eigentlich nur eine Art "Statusdevice" für den daemon bzw. ESP, alle anderen Teilnehmer auf dem Bus sollten dann separate Devices ergeben.
Unklar ist mir, für was die Devices dann stehen, die "630" scheint irgendein Typ Brennwertkessel oä. zu sein. Soweit, so gut.
Was du jetzt gemacht hattest, war, das "bridgeing" zu "umgehen", indem du die readingList erweitert hattest, und alles in dem Statusdevice zu belassen. Kann man machen, für die Handhabung im Rahmen von Sprachsteuerung erscheint es mir einfacher, wenn jede Baugruppe eben ein eigenes Device ist.
Jetzt habe ich das Ding von neulich nochmal runtergestrippt, dass da nur noch das drin steht, was zu "hc" gehört - geht aber nur bei allem, was ich irgendwie halbwegs eindeutig zuordnen kann, nicht aber beim jsonMap, weil ich die Quelle der Readings nicht kenne.
Daher jetzt mal das als Zwischenergebnis (mit den weggelassenen homebridgeMappings, soweit nach den Tests möglich):
defmod MQTT2_ebusd_test MQTT2_DEVICE ebusd_hc
attr MQTT2_ebusd_test IODev ebusMQTT
attr MQTT2_ebusd_test alexaName EBUSHaZe
attr MQTT2_ebusd_test alias EBUSHaZe
attr MQTT2_ebusd_test autocreate 1
attr MQTT2_ebusd_test genericDeviceType thermostat
attr MQTT2_ebusd_test icon sani_boiler_temp
attr MQTT2_ebusd_test readingList
ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }\
ebusd/hc/Params:.* { json2nameValue($EVENT, 'Params_', $JSONMAP) }\
ebusd/hc/Status:.* { json2nameValue($EVENT, 'Status_', $JSONMAP) }\
ebusd/hc/Status16:.* { json2nameValue($EVENT, 'Status16_', $JSONMAP) }\
ebusd/hc/Params/get:.* get
attr MQTT2_ebusd_test homebridgeMapping TargetHeatingCoolingState=mode,values=OFF:OFF;;HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;COOL:OFF\
history:size=1024
attr MQTT2_ebusd_test jsonMap Status16_temp_value:measured-temp Status_2_value:desired-temp Mode_hcmode1_value:mode Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
attr MQTT2_ebusd_test setList getKnown:noArg ebusd/list onlyknown\
getAll:noArg ebusd/list\
Params ebusd/hc/Params/get\
mode:uzsuDropDown,ON,OFF,AUTO,ECO,LOW ebusd/hc/SetMode/set $EVTPART1\
MinVLTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetFlowTempMin/set $EVTPART1\
MaxVLTemp:uzsuDropDown,60,61,62,63,64,65,66,67,68,69,70 ebusd/hc/SetFlowTempMax/set $EVTPART1\
AussenAusTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetShutdownTemp/set $EVTPART1\
AbsenkTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetTempDesiredLow/set $EVTPART1\
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
Grundsätzlich gebe ich dir aber recht, hier müßten noch ein paar andere mit überlegen, was wie Sinn macht, v.a. welche, die grade dabei sind, in das Thema einzusteigen und es "einfach" haben wollen.
Interessehalber: Hast du je was mit Wochenplänen gemacht? Ich habe mir einen Teil der dummy-Geschichte mal angesehen, bin aber nicht so recht schlau draus geworden und hatte am Ende nur den Eindruck, dass das eigentlich so nicht richtig funktionieren kann, schon alleine, weil Daten zu einem Zeitpunkt verwendet werden, zu dem sie noch gar nicht (aktuell) geliefert worden sind. Aber evtl. verstehe ich da auch was falsch...
zur Info, die Geräte wie 350, 430, 470, 630 usw sind die Zusatz Regler (calormatic) für die Heizgeräte. An ihnen kann dann ein Außenfühler angeschlossen werden und ermöglich dann eine Witterungs geführte Regelung mit verschiedenen Heizkurven. Auch die Zeitprogramme werden da gespeichert und bieten noch jede Menge zusätzliche Datenpunkte. Diese Regler kommunizieren dann mit dem Masterdevice. Der Masterdevice muss nicht unbedingt einen eigenen Regler haben, der funktioniert auch so, eben ohne dem zusätzlichen Komfort wie Heizkurven und so.
D.h. ein und dasselbe Heizgerät kann verschiedene Regler angeschlossen haben, deshalb hat jede Calormatic unterschiedliche Datenpunkte, manche sind gleich, manche bei älteren gar nicht vorhanden. Das ist auch der Grund, warum es dazu jeweils ein eigenes Datenbankfile (csv) dazu gibt. Die Entwicklung von Vaillant geht ja ständig weiter und die csv wurden schon vor vielen Jahren erstellt, daher das Problem mit "neueren" Geräten. Daher wer ein solches Device das nicht von einer csv unterstützt wird, muss sich das zunächst selber erstellen. Das ist mit viel Aufwand und Revers Engineering verbunden und sehr zeitaufwändig.
Ich empfehle daher immer zuerst mit der Auswertung der Schnittstellen Daten zu beginnen und erst wenn alles läuft die Visualisierung mittels templates etc.
Im Endeffekt kann ein und dasselbe Heizgerät durch die vielen optionalen Regler von User zu User in Fhem immer anders aussehen. Die templates die du damals erstellt hast, waren auf Basis einer Calormatic 430.
Ich hoffe ich konnte etwas Licht in den Bezeichnungsdschungel bringen.
LG
Danke, etwas heller ist es geworden.
dass das mit den csv-files jeweils eine spezielle Sache ist, war soweit klar, wobei mich etwas wundert, dass es keine wirkliche Standardisierung der "gewünschten" Benennungen (von mir aus je in de bzw. en) zu geben scheint.
Dass erst die Basis von dieser Seite aus passen sollte, ist eigentlich auch klar, wobei bei den jetzigen attrTemplates eben das Problem besteht, dass der "Kreis" zwischen FHEM-Anweisung und Ergebnis auf dem Gerät häufig (?) nicht geschlossen zu sein scheint. Also: "setze Wunschtemperatur am hc (?)" wird von FHEM aus auf den ebus geschrieben, es kommt aber "Temperatur xyz ist jetzt nn" (auf Anfrage?) zurück. Diesen Kreis sollte man mAn. (exemplarisch) schließen (unter Verwendung von "guten" Reading-Namen) und das Vorgehen auch im Wiki darstellen, bevor die nächste Welle von Anwendern dazukommt. Dazu könnte mAn. auch das manuelle at entfallen, weil man (zwischenzeitlich) dasselbe direkt am jeweiligen MQTT2-Teil-Gerät via periodicCmd einstellen könnte. Wäre mAn. im Ergebnis einfacher zu verstehen, weil man dann als Anwender immer nur den jeweiligen Teilaspekt ansieht.
Just my2ct.
Zitat von: Beta-User am 17 November 2020, 11:46:09
...
dass das mit den csv-files jeweils eine spezielle Sache ist, war soweit klar, wobei mich etwas wundert, dass es keine wirkliche Standardisierung der "gewünschten" Benennungen (von mir aus je in de bzw. en) zu geben scheint.
...
Das hatte ich ja schon versucht zu vermitteln, dass es nicht ohne ist.
Es ist denke ich
nicht in kurzer Zeit machbar.
Theoretisch sind es ja "nur" 3 Readings und 2 Set´s die man einheitlich gestalten müsste, aber eine Vielzahl an "Baugruppen"....
Bin aber gerne bereit zu helfen wie ich kann...
mfg
Zitat von: Beta-User am 16 November 2020, 14:47:26
Interessehalber: Hast du je was mit Wochenplänen gemacht? [...]
Zitat von: Beta-User am 17 November 2020, 11:46:09
[...] wobei bei den jetzigen attrTemplates eben das Problem besteht, dass der "Kreis" zwischen FHEM-Anweisung und Ergebnis auf dem Gerät häufig (?) nicht geschlossen zu sein scheint. Also: "setze Wunschtemperatur am hc (?)" wird von FHEM aus auf den ebus geschrieben, es kommt aber "Temperatur xyz ist jetzt nn" (auf Anfrage?) zurück. Diesen Kreis sollte man mAn. (exemplarisch) schließen (unter Verwendung von "guten" Reading-Namen) und das Vorgehen auch im Wiki darstellen, bevor die nächste Welle von Anwendern dazukommt. Dazu könnte mAn. auch das manuelle at entfallen, weil man (zwischenzeitlich) dasselbe direkt am jeweiligen MQTT2-Teil-Gerät via periodicCmd einstellen könnte. Wäre mAn. im Ergebnis einfacher zu verstehen, weil man dann als Anwender immer nur den jeweiligen Teilaspekt ansieht.
Da hier keiner den Ball so richtig aufnehmen wollte die Zwischeninfo, dass wir just diese Themen grade an einem "normalen" Heizungsgerät durchspielen: Antw:Zigbee2MQTT - Template für Thermostat (https://forum.fhem.de/index.php/topic,116535.msg1109290.html#msg1109290).
Dass das ganze - hier wie dort - "nicht ohne ist", ist klar, aber ggf. werden meine möglicherweise etwas kryptischen Ausführungen hier in diesem Thread mit dem etwas weniger komplexen Device dort (und dem MQTT - workshop (https://forum.fhem.de/index.php/topic,116162.0.html), der aber zugegebenermaßen auch ziemlich schnell eher "für Fortgeschrittene" ist) etwas besser verständlich und konkreter...
Jedenfalls gäbe es dort zum einen Beispielcode, der das Temperaturlisten-Array separat extrahiert und myUtils-Code, der aus/mit weekprofile dann "andere" Temperaturlisten-Formate erzeugt und direkt auch versenden könnte. Sollte beides eigentlich nicht allzu schwer auf den hiesigen Anwendungsfall anpassbar sein, im Kern ist es jetzt eigentlich nur noch "einfaches" Textpuzzeln mit Arrays...
Nachdem an anderer Stelle Fragen aufgetaucht sind:
Zitat von: beaune am 14 Juni 2021, 10:48:56
Bei den Templates ist mir nicht ganz klar, wo eigentlich die aktuellen offiziell abgelegt sind. Ich hab zwei Versionen: eine, wo die Template-Namen ein vorangestelltes E_ haben und eine ohne. Eigentlich hätte ich erwartet, dass ich die versionierten Templates im fhem-Repo finde, aber da sind sie anscheinend nicht. Was ist denn jetzt aktuell?
Es gibt das "Basis-attrTemplate" zu ebus, das ist in mqtt2.template zu finden, zur Verfolgung von Änderungen kann man https://svn.fhem.de/trac/log/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template verwenden, eine Versionsinfo wird (aktuell) durch
setreading DEVICE attrTemplateVersion 20200824hinterlegt, was in etwa bedeutet: Das Basistemplate wurde zuletzt am 24.08.2020 verändert.
Die weiteren attrTemplate sind im svn in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/mqtt2.ebus.template zu finden; das ist afaik im Prinzip der letzte Stand von Reinhart. "Im Prinzip" deswegen, weil zwar inhaltlich nichts geändert wurde, aber z.B. die Sortierung nicht mehr über den Namen erfolgen muss, sondern über einen internen Kenner. Wer also noch E_.*-attrTemplates zur Auswahl hat, hat eventuell eine (doppelte) ältere Version, aber vermutlich jedenfalls nichts neueres.
Zitat von: Reinhart am 16 Juni 2021, 10:06:10
da bei den Templates im allgemeinen kein oder wenig Interesse herrscht habe ich da auch nicht mehr weiter gemacht. Es ist auch schwer die Templates für alle Geräte einheitlich zu gestallten.
Bin nach wie vor nicht überzeugt, dass es dafür keinen Bedarf gibt. Insbesondere _glaube_ ich, dass der Kreis bei manchen Readings von FHEM (set-Anweisung) nach eBus nach FHEM (jsonMap) nicht sauber geschlossen ist und es sinnvoll wäre, ein paar (allgemeingültige?) Beispiele zu zeigen. Das Know-How betr. MQTT2_DEVICE dürfte zwischenzeitlich bei einigen Usern da sein, um zumindest RAW-Definitionen zu zeigen, die das "gut" machen.
Zitat
Ich fänd auch eine Übersicht gut, was es alles an relevanten Templates gibt.
Eigentlich sollten die beim Hauptdevice in der dropdown-Auswahl zu finden sein und alle beieinanderstehen. Es gibt auch einen Wiki-Artikel, der die Visualisierungen (via readingsGroup) zeigt.
Zitat
Da gibt's zwar den Mechanismus mit dem automatischen Nachladen, aber das find ich irgendwie zu spooky und würd das eigentlich viel lieber selbst beeinflussen können, welche Tempates ich haben möchte. Aber dafür bräuchte man eben ein Repo o.ä., damit man sieht was es gibt, und auch Änderungen nachvollziehen kann. Gibt's da was?
Ich kann nicht nachvollziehen, wieso das "spooky" sein soll, erneuerten Content aus dem svn zu ziehen, sei es via update oder via Svn_GetFile().
Wer skeptisch ist, kann zum einen vorab die Änderungen ansehen, und zum anderen sind "heruntergeladene attrTemplate" noch lange keine "angewendeten attrTemplate": Das ganze wirkt sich erst aus, wenn man sie anwendet. Und auch zu dem Zeitpunkt sieht man dann wieder (in FHEMWEB), was passieren wird, wenn man das via dropdown auswählt...
Wer das dann nicht "gut" findet, kann ja immer noch "händisches Cherrypicking" betreiben und die Attribute händisch so setzen, wie er es für richtig findet.
(Klar ist das ganze keine Garantie, dass nicht auch mal was schiefgeht, aber so sind wenigstens alle (potentiell) auf demselben Stand und man kann sich wechselseitig helfen...)
Hallo Leute.
Ich habe endlich meinen ebus3-Adapter produktiv nehmen können. Docker läuft mit CSV-Configs für Weishaupt (aus Joek3rs Repo), MQTT-Devices sind gem. WIKI angelegt und das ebus-splitter-Template erfolgreich angewandt. Jetzt würde ich gern ein paar Verständnisfragen platzieren:
WIKI sagt:
Zitat...D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai)...
Woher weiß ich, welches Template ich benötige/ mir wünsche?
Sind die "ebus-Spezifische weitere Templates" vom Hersteller abhängig? BAI und Co. klingen irgendwie nach Vaillant, bei mir hab ich soetwas anscheinend nicht. Passt eines der Templates auch für Weishaupt (welches)?
Kann ich einfach Templates setzen und gefahrlos notfalls wieder zurückrollen und dann das nächste Templ. testen?
Sorry für die doofen Fragen. Taste mich langsam ran und ebus scheint imho komplex (viele Themen zum Einlesen).
Vielen Dank und beste Grüße
rob
PS: Zwei Kleinigkeiten sind mir nebenher aufgefallen. Im Wiki steht:
ZitatDie eBus Templates beginnen alle mit E....
--> aktuell fangen sie nun mit "eBus..." an. Ungefragt möchte ich das nicht einfach im WIKI ändern.
Bei einem Templatenamen hat sich vorne ein "e" verdünnisiert --> "Bus_bai_readingsgroup_eBusCounter"
Zitat von: rob am 12 Juli 2021, 23:13:14
Woher weiß ich, welches Template ich benötige/ mir wünsche?
Optimalerweise sollte sich das aus der "desc" ergeben (=angezeigter Infotext, der unter dem setter angezeigt wird, wenn man was aus dem dropdown auswählt bzw. "?" "anwendet"), und/oder aus dem, was man an Code vorab angezeigt bekommt, den das attrTemplate ausführt.
Wie an anderer Stelle schon geschrieben: M.E. entsprechen die eBus-templates nicht mehr in allen Punkten dem Stand der Technik bzw. der Kenntnisse und Möglichkeiten, was sich z.B. auch bei dem Benennungsthema niederschlägt: Ganz zu Beginn war (nur) der Name des jweiligen attrTemplate für die Sortierung innerhalb der Liste relevant, weswegen eben alle "E_irgendwas" benannt waren. Als "order" eingeführt wurde, habe ich die Namen vereinfacht, da ist mir das "e" vermutlich verlustig gegangen...
Ein update - auch im Wiki - könnte daher nicht schaden; heute würde man vermutlich schreiben, dass die zusätzlichen Templates dann runtergeladen werden/sichtbar werden, wenn das Basistemplate (splitter) ausgeführt wurde und dann unterhalb des "splitters" zu finden sind (so sollte es jedenfalls sein...).
ZitatKann ich einfach Templates setzen und gefahrlos notfalls wieder zurückrollen und dann das nächste Templ. testen?
Im Prinzip: ja.
Ich empfehle in solchen Fällen, die von autocreate erstellte RAW-Definition wegzusichern, dann kann man immer zurück auf den Ausgangszustand. Etwas schwieriger ist es, wenn - wie teilsweise hier - zusätzliche Geräte erstellt werden. Dann muss man ggf. manuell diese zusätzlichen Geräte löschen, wenn sie einem nicht gefallen bzw. nicht das tun, was man erwartet.
Zitat
Sind die "ebus-Spezifische weitere Templates" vom Hersteller abhängig? BAI und Co. klingen irgendwie nach Vaillant, bei mir hab ich soetwas anscheinend nicht. Passt eines der Templates auch für Weishaupt (welches)?
Kann ich ohne RAW-Defs nicht sagen, und vermutlich würde es auch nicht schaden, die Topic/payload-Kombinationen zu kennen (dann kann ich nachvollziehen, warum welche Readings gebaut werden und ggf. auch manches nachstellen).
Zitat
Sorry für die doofen Fragen. Taste mich langsam ran und ebus scheint imho komplex (viele Themen zum Einlesen).
M. E. sind die Fragen nicht doof, und auch nach meinem Eindruck ist die Auswertung der Daten teilweise ziemlich tricky, nicht zuletzt, weil verschiedene Hersteller dahinter stehen und/oder teilweise die csv-Dateien nicht "standardisiert" sind.
Wir können da gerne einen Anlauf nehmen, das für "Weishaupt" gemeinsam so aufzubereiten, dass es dem aktuellen Stand der Dinge entspricht ;) .
@Beta-User: Vielen Dank für Deine flinke Antwort.
Mir geht es auch nicht drum etwaige "Schwachstellen" aufzudecken, sondern zunächst halbwegs das Machbare zu verstehen. Wenn nebenher andere User profitieren können, umso besser.
Daten usw. stelle ich gerne zur Verfügung. Passt das denn so Weishaupt-spezifisch hierher oder sollte ich das besser in einem eigenen Fred abtrennen? Ähnliches wurde ja schon im ebus-Fred angeregt. Hab ich auch kein Problem mit.
Vielen Dank und beste Grüße
rob
Zitat von: rob am 13 Juli 2021, 09:38:23[...] zunächst halbwegs das Machbare zu verstehen. Wenn nebenher andere User profitieren können, umso besser.
Erfahrungsgemäß bedingen sich beide Dinge ;) .
ZitatDaten usw. stelle ich gerne zur Verfügung. Passt das denn so Weishaupt-spezifisch hierher oder sollte ich das besser in einem eigenen Fred abtrennen? Ähnliches wurde ja schon im ebus-Fred angeregt. Hab ich auch kein Problem mit.
Ob es ggf. "spezifisch" ist, kann ich ohne Daten nicht beurteilen, und ich würde auch meine Hilfe gerne möglichst auf die Funktionalität beschränken, die MQTT2_DEVICE bietet.
Dem Bauchgefühl nach würde ich dazu tendieren, einen neuen Thread im MQTT-Bereich auzumachen (der von hier aus verlinkt werden darf!), und dort mit "eBus + Weishaupt auf der grünen Wiese" zu starten. Ist dann ggf. für Nachahmer leichter und "am Stück" nachzuvollziehen, wie das im Einzelnen aufeinander aufbaut, und ggf. klinkt sich dann auch @beaune mit ein (siehe z.B. die Detailfrage hier: https://forum.fhem.de/index.php/topic,122029.msg1166237.html#msg1166237).
Als vorbereitende Lektüre würde ich empfehlen, den "MQTT-Workshop (https://forum.fhem.de/index.php/topic,116162.0.html)" zumindest mal zu überfliegen. Ist sehr "harter Stoff", und du musst auch nicht alles verstehen, aber der gibt einen halbwegs vollständigen Überblick über alle möglichen Lösungen, die mit und um MQTT2_DEVICE bisher entwickelt worden sind, so dass es gut wäre, du hättest zumindest einen ersten Eindruck davon, was man alles machen kann...
Vielleicht auch ein guter Einstieg, wie man z.B. JSON "einfängt": https://forum.fhem.de/index.php/topic,117405.0.html
habe ich gemacht. In diesem Thread geht es mit dem konkreten Thema weiter: https://forum.fhem.de/index.php/topic,122048.0.html (https://forum.fhem.de/index.php/topic,122048.0.html)
VG
rob
Hallo Ihr Profis,
ich habe ein riesen Problem:
1. wo befinden sich die Template Dateien?
2. wo finde ich eine Vorlage für die Vaillant 630/4 ?
3. kommt eigentlich bei mir was an , ich bekomme immer nur nichts sagende Meldungen wie:
ebusctl info
version: ebusd 3.0.595c7c0
update check: version 22.3 available, broadcast.csv: newer version available
signal: acquired
symbol rate: 50
max symbol rate: 125
oder:
busctl scan result
-bash: line 72: pi@raspberrypi:~$: command not found
/opt/fhem/FHEM/lib/AttrTemplate$ ebusctl scan result
08;Vaillant;BAI00;0703;7401
23;Vaillant;SOLSY;0500;6301
25;Vaillant;SOLSY;0500;6301
26;Vaillant;SOLSY;0500;6301
50;Vaillant;SOLSY;0500;6301
ec;Vaillant;SOLSY;0500;6301
Ich habe es mittlerweile mit : ECMD und MQTT Server versucht, GAEBUS lässt sich erst gar nicht installieren. ( Modul kann nicht gefunden werden. Datei GAEBUS ist aber an der richtigen Stelle ( laut Bescheibung ) vorhanden.
Nachdem ich nun gefühlte 500 Seiten gelesen habe, mir der Kopf qualmt und ich nach jeder Info mehr Fragen als vorher habe bin ich nicht sicher ob ich da jemals was sinnvolles herausbekomme.
Muss ich HTML, Perl, Linux und .... beherrschen um zu vertehen, was die "Vorlagen" mit nicht zusammengehörenden Codeschnipseln mir sagen?
Leider finde ich auch keine sinnvolle Auflistung der Befehle für die Abfrage des ebus. Somit weiss ich nicht, wie ich herausbekomme, ob da nun was kommt, ob das mit der 630 überhaupt geht, noch habe ich irgendeinen Wert erhalten, nur MAsken , wo immer 00 drin steht. das Protokoll weist keinen Fehler auf:
2022.07.12 09:32:31 1: Including fhem.cfg
2022.07.12 09:32:31 3: telnetPort: port 7072 opened
2022.07.12 09:32:32 3: WEB: port 8083 opened
2022.07.12 09:32:32 3: WEBphone: port 8084 opened
2022.07.12 09:32:32 3: WEBtablet: port 8085 opened
2022.07.12 09:32:32 2: eventTypes: loaded 46 lines from ./log/eventTypes.txt
2022.07.12 09:32:32 3: tablet_ui: new ext defined infix:ftui/: dir:./www/tablet:
2022.07.12 09:32:32 3: Registering HTTPSRV tablet_ui for URL /ftui and assigned link ftui/ ...
2022.07.12 09:32:32 3: Opening EBUS device 192.168.146.10:8888
2022.07.12 09:32:32 3: EBUS device opened
2022.07.12 09:32:32 3: ebusMQTT: port 1883 opened
2022.07.12 09:32:32 3: Can't create ./www/deviceimages
2022.07.12 09:32:32 3: Can't create ./www/deviceimages/mqtt2
2022.07.12 09:32:32 1: Including ./log/fhem.save
2022.07.12 09:32:32 0: Featurelevel: 6.1
2022.07.12 09:32:32 0: Server started with 32 defined entities (fhem.pl:26115/2022-06-04 perl:5.028001 os:linux user:fhem pid:31103)
Was kann ich machen um das zu verstehen?
Grüsse
KarLOs
Hmm, für mich als nicht-Ebus-Nutzer sieht das so aus, als würdest du die csv-Dateien, die man für eine sinnvolle Kommunikation zwischen den Heizgeräten selbst und ebusd benötigt, in einen Topf werfen mit mqtt2-attrTemplate, das als Hilfestellung für die Auswertung der von ebusd gesendeten Daten an FHEM (via MQTT) gedacht sind.
Demnach wärst du hier m.E. mit dem Anliegen falsch (ich kann aber auch falsch liegen).
Jedenfalls: Bitte hier keine Diskussion zur ebus-Konfiguration mit Hilfe von csv-Dateien. (Wer weiterhelfen kann, kann selbstredend gerne einen link dahin posten, wo dazu was zu finden ist!)
Ja, liest sich für mich auch so ;) - bin aber kein Profi.
Wenn Du zufällig den ebus-Adapter V3 nutzt, wäre dies ggf. der richtige Fred: https://forum.fhem.de/index.php/topic,118143.0.html (https://forum.fhem.de/index.php/topic,118143.0.html)
Und wenn es der V2.x ist, dann dieser https://forum.fhem.de/index.php/topic,84636.msg769462.html#msg769462 (https://forum.fhem.de/index.php/topic,84636.msg769462.html#msg769462)
VG
rob
Entweder forderst du die Daten über das IO-Device (MQTT2_SERVER/MQTT2_CLIENT) an (das verwendest du offensichtlich nicht in deinem at?), oder du erstellst Dir entsprechende setter||getter in einem deiner MQTT2-Devices, die du dort mit Hilfe des Attribut periodicCmd auch regelmäßig ausführen lassen kannst.
ZitatperiodicCmd <cmd1>:<period1> <cmd2>:<period2>...
periodically execute the get or set command. The command will not take any arguments, create a new command without argument, if necessary. period is measured in minutes, and it must be an integer.
Vermutlich, ich schreibe bisher nix, sind es die doppelten Semikolon, es wird nur eins erwartet, denk ich.
ZitatWie kann ich den zusammengesetzen Aufruf sichtbar machen ?
In der Zeile steht im Log das was zusammengesetzt wurde:Oder wenn du oben in der Kommandozeile auf der Perlebene alles eingibst was an den FHEM-Befehl angehangen wird :
Schau im Traffic Monitor des MQTT2-Server, was wie gesendet wurde.
Und ?
Wird das jetzt übernommen oder kommt es zu der Meldung von oben:
Zitat2023-10-15 14:45:58.398 [bus error] prepare message part 0: ERR: end of input reached
2023-10-15 14:45:58.398 [mqtt error] write 470 hcTimer.Sunday: ERR: end of input reached
ReadingsVal("TimeSo","HHMM1su",0) vs.
ReadingsVal("TimeSu","HHMM1su",0)
und als Ersatzwert würd ich bei ReadingsVal einen String verwenden bspw "00:00" "-:-"
Hallo,
Ich hatte mir vor einiger Zeit auch diverse eins-Templates angeschaut. Sie bieten einige interessante Anregungen, sind letztendlich aber für einen produktiven Einsatz wenig geeignet. Ich nutze für diesen Zweck weekdaytimer. Ich hatte hier ein paar Erweiterungen angeregt, die leider abgelehnt wurden. Da ich das für mich aber schon implementiert hatte, hab ich mir einen Clone des Moduls gemacht und nutze das seitdem ohne Probleme. Details sieht hier:
Zitat von: beaune am 02 September 2021, 10:35:35Hallo,
zur Zeit wird in mehreren Threads zum eBus die Nutzung des weekprofile-Moduls für die Konfiguration von Zeitplänen in Heizungssteuerungen diskutiert. Ich habe mir das mal genauer für meine Vaillant-Anlage angesehen, und einige grundlegende Unterschiede in der Anwendung/Erwartungshaltung festgestellt:
- Bei der direkten Ansteuerung von Ventilen usw. ist fhem der ,,Master", der die Zeitprofile verwaltet und auf mehrere Geräte verteilt. Bei einer Heizungsanlage ist fhem nur das Vehikel, um Zeitpläne einzugeben. Die Verwaltung und Auswertung liegt weiterhin in der Heizungsanlage selbst.
- Bei der direkten fhem-Steuerung gibt man zu jedem Zeitintervall eine Soll-Temperatur ein. Bei Heizungsanlagen ist die Soll-Temperatur aber zentral verwaltet; die Zeitintervalle steuern nur, ob die Heizung im Normalbetrieb oder im Nachabsenkungsbetrieb läuft. Man konfiguriert dort also keine Temperaturwerte im Rahmen der Zeitprofile, und zeigt auch nur die ,,on"-Intervalle an, in denen die Heizung im Normalbetrieb läuft.
- Die Anzahl der möglichen Zeitintervalle ist durch die Heizungssteuerung fest vorgegeben; man kann nicht beliebig viele definieren.
- Die möglichen Profile (=Heizkreise bzw. Warmwasserbereitung) sind ebenfalls fest durch die Installation vorgegeben.
Man könnte jetzt sagen, die beiden Szenarien unterscheiden sich so stark, dass man dafür auch verschiedene Eingabemodule braucht. Es ist auch bestimmt nicht gut, zu viele Verzweigungen in ein Modul zu packen. Ich glaube aber in diesem Fall, dass es nicht so schwierig ist, beides in einem Modul zu vereinen, und hab einfach mal einen entsprechenden Vorschlag gemacht. Sieht auf den ersten Blick viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für eine Heizungssteuerung verwenden, behält aber auch alle vorhandenen Möglichkeiten, die man für eine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle und kompatible Ergänzung des Moduls. Bin gespannt was Ihr dazu sagt, und ob meine Anregungen vielleicht sogar ins Einzug ins Repository finden ;-)
Neue Attribute:
- maxNumInterval: limitiert die Anzahl eingebbarer Zeitintervalle zwischen 1 und 10; Default: 0 (=unlimitiert)
- fixedProfileSettings: Verhindert das Hinzufügen und Löschen von Profilen über die Oberfläche. Die Option ist sinnvoll in Verbindung mit Geräten, die über eine feste Anzahl und Typen von Profile verfügen, z.B. Heizungen. Default: 0
- hideTemperatureSettings: Blendet die Temperatureinstellungen sowohl in der Übersicht aus auch beim Editieren aus, und trägt stattdessen automatisch ,,on" bzw. ,,off" als Temperaturwert ein. In der Übersicht werden die Off-Intervalle ausgeblendet.
Die Option ist sinnvoll in Verbindung mit Geräten, die globale Temperatureinstellungen unabhängig vom Intervall verwalten, und bei den Intervallen nur die on-Intervalle konfiguriert werden, z.B. bei Heizungen. Default: 0 - showLoadButton: Wenn auf 1 gesetzt, blendet FHEM einen zusätzlichen Button ein, bei dessen Aufruf das Event LOAD_FROM_DEVICE getriggert wird.
Die Option ist sinnvoll, wenn man direkt aus dem WeekProfile Control heraus ermöglichen will, vor dem Editieren Daten aus einem Gerät zu lesen. Das gewählte Profil wird im Event mit übertragen. Default: 0. - hideTransferButton: Wenn auf 1 gesetzt, wird der Button zum Transfer des gewählten Profils auf auswählbare FHEM-Devices ausgeblendet. Die Option ist sinnvoll, wenn direkt nach der Eingabe neuer Daten die weitere Verarbeitung ohne weitere User-Interaktion durchgeführt werden soll. Dies kann über Auswertung des Events WRITE_TO_DEVICE geschehen. Default: 0
- nolink: Wenn auf 1 gesetzt wird verhindert, dass der rechts neben dem Edit-Icon stehende Modulname ein Link ist (wie bei readingsGroups). Default: 0
- noheadings: Wenn auf 1 gesetzt wird verhindert, dass oberhalb des Controls nochmal der Modulname ausgegeben wird (wie bei readingsGroups). Default: 0
Neue Events:
- LOAD_FROM_DEVICE: wird aufgerufen, wenn der durch showLoadButton eingeblendete zusätzliche Button betätigt wird. Das aktuell ausgewählte Profil wird mit übergeben.
- WRITE_TO_DEVICE: wird aufgerufen, nachdem neue Daten gespeichert wurden. Das aktuell ausgewählte Profil wird mit übergeben, so dass der Anwender per notify entscheiden kann, welche Geräte automatisch mit neuen Daten versorgt werden sollen.
Sieht viel aus, war im Grunde aber relativ einfach, und ist von der Implementierung her sehr überschaubar. Hab alle auskommentierten oder hinzugefügten Zeilen mit ,,beaune" kommentiert. Mit diesen Erweiterungen lässt sich weekprofile perfekt als Eingabemaske für ein spezifisches Gerät spezialisieren, und wird damit auch ,,kleinen" Anlagen gerecht, wo man wirklich nur die Heizung einstellen will und keine szenenbasierte Einzelraumregelung o.ä. braucht. Aus meiner Sicht eine sinnvolle Ergänzung des Moduls. Bin gespannt, ob sich jemand dafür interessiert, oder was Ihr noch verbessern würdet. Die Implementierung und zwei Screenshots sind hier angehängt.
Zitat von: piuser1 am 15 Oktober 2023, 17:16:36Leider keine Verbesserung - das Template ist wahrscheinlich quick and diry entstanden, habe jetzt mehr als 6 Stunden damit verbracht, ich glaube es reicht !
Hab mich hinreissen lassen am Ende doch_wieder_zu_lange damit zu befassen, obwohl ich das gar nicht brauche.
Ich bezweifle das es am Template liegt.
Bei mir funktioniert dein in Perl (den geschweiften Klammern) ausgeführter FHEM-Befehl in der Kommandozeile problemlos:
{fhem ("set MQTT2_Server publish ebusd/700/hwcTimer.Monday/set " . '-:-' . chr(59) . chr(59) . '-:-' . chr(59) . chr(59) . '-:-' . chr(59) . chr(59) . '-:-' . chr(59) . chr(59) . '-:-' . chr(59) . chr(59) . '-:-' . chr(59) . chr(59) . 'selected')}Traffic-Monitor (Wie man sieht kommt direkt unangefordert eine Rückmeldung zurück):
18:26:26.521 SENT ebusd/700/hwcTimer.Monday/set -:-;-:-;-:-;-:-;-:-;-:-;selected
18:26:26.692 ebusd_3.3_746 ebusd/700/hwcTimer.Monday {(10) "0": {"name": "from", "value": "-:-"},(10) "1": {"name": "to", "value": "-:-"},(10) "2": {"name": "from", "value": "-:-"},(10) "3": {"name": "to", "value": "-:-"},(10) "4": {"name": "from", "value": "-:-"},(10) "5": {"name": "to", "value": "-:-"}}ebusd-Log:
2023-10-17 18:26:26.687 [update notice] sent write 700 hwcTimer.Monday QQ=31: -:-;-:-;-:-;-:-;-:-;-:-
2023-10-17 18:26:26.688 [mqtt notice] write 700 hwcTimer.Monday: -:-;-:-;-:-;-:-;-:-;-:-;selectedDirekt am MQTT2_Server:
set MQTT2_Server publish ebusd/700/hwcTimer.Monday/set 00:10;-:-;-:-;-:-;-:-;-:-;selectedTraffic-Monitor:
18:13:56.455 SENT ebusd/700/hwcTimer.Monday/set 00:10;-:-;-:-;-:-;-:-;-:-;selected
18:13:56.613 ebusd_3.3_746 ebusd/700/hwcTimer.Monday {(10) "0": {"name": "from", "value": "00:10"},(10) "1": {"name": "to", "value": "-:-"},(10) "2": {"name": "from", "value": "-:-"},(10) "3": {"name": "to", "value": "-:-"},(10) "4": {"name": "from", "value": "-:-"},(10) "5": {"name": "to", "value": "-:-"}}ebusd-Log:
2023-10-17 18:13:56.598 [update notice] sent write 700 hwcTimer.Monday QQ=31: 00:10;-:-;-:-;-:-;-:-;-:-
2023-10-17 18:13:56.608 [mqtt notice] write 700 hwcTimer.Monday: 00:10;-:-;-:-;-:-;-:-;-:-;selectedEine weitere Variante, alternativ zu der aus dem Template:
{ fhem("set MQTT2_Server publish ebusd/700/hwcTimer.Monday/set " .sprintf("%s%c%c%s%c%c%s%c%c%s%c%c%s%c%c%s%c%c%s%c%c%s",'-:-',59,59,'-:-',59,59,'-:-',59,59,'-:-',59,59,'-:-',59,59,'-:-',59,59,'selected'))}Traffic-Monitor:
18:17:54.904 SENT ebusd/700/hwcTimer.Monday/set -:-;-:-;-:-;-:-;-:-;-:-;selected(0)(0)
18:17:55.043 ebusd_3.3_746 ebusd/700/hwcTimer.Monday {(10) "0": {"name": "from", "value": "-:-"},(10) "1": {"name": "to", "value": "-:-"},(10) "2": {"name": "from", "value": "-:-"},(10) "3": {"name": "to", "value": "-:-"},(10) "4": {"name": "from", "value": "-:-"},(10) "5": {"name": "to", "value": "-:-"}}ebusd-Log
2023-10-17 18:17:55.038 [update notice] sent write 700 hwcTimer.Monday QQ=31: -:-;-:-;-:-;-:-;-:-;-:-
2023-10-17 18:17:55.038 [mqtt notice] write 700 hwcTimer.Monday: -:-;-:-;-:-;-:-;-:-;-:-;selected
Hast du mal geschaut ob man die Meldung
00: ERR: invalid position
bei Dir nicht einfach ignorieren kann und die Werte doch übernommen werden ?
Es findet bei dir doch ein schreiben statt?
2023-10-15 17:14:48.293 [mqtt notice] write 470 hcTimer.Monday: 04:20;09:00;11:00;20:00;-:-;-:-;selected Sieht genauso aus wie bei mir.
Die Meldungen
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Monday: ERR: invalid position
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Tuesday: ERR: invalid position
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Wednesday: ERR: invalid position
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Thursday: ERR: invalid position
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Friday: ERR: invalid position
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Saturday: ERR: invalid position
2023-10-15 17:14:51.333 [mqtt error] decode 470 hcTimer.Sunday: ERR: invalid position lassen mich dann aber doch zweifeln das es trotzdem geklappt haben könnte.
Wenn das schreiben bei dir nicht klappt, dann würd ich einfach mal auf Github fragen, wenn John30 hier nicht mitliest, evt. kann er ja was dazu sagen, was bei deiner 470 zu der Meldung
00: ERR: invalid position führt.
Evtl. hat es etwas damit zu tun was er hier (https://forum.fhem.de/index.php?msg=925723) unten schon erwähnt hat, trotz das es damals um eine 430 ging.
Ist es zuviel verlangt die gezeigten Beispiele einfach mal Stück für Stück nachzuvollziehen und hier dann die Ausgaben des ebusd-Log zu zeigen ?
Hier nochmal eine weitere simple Möglichkeit für dich zum testen.
In diesem automatisch angelegten Device:
https://forum.fhem.de/index.php?topic=135318.msg1289455#msg1289455
in dem Attribut setList folgendes eintragen:
hcTimerMonday:textField ebusd/470/ccTimer\x2eMonday/set $EVTPART1den setter hcTimerMonday wählen und in dem Textfeld dahinter dann die Zeiten eintragen, bspw.:
04:20;09:00;11:00;20:00;-:-;-:-;selected
Was steht dann im ebusd-Log ?
ZitatWenn man das Template erst analysieren/Fehlersuche machen muss, dann scheint was schiefgelaufen zu sein ;)
Mein Verdacht ist weiterhin das es nicht am Template liegt und du nicht bereit bist der Sache auf den Grund zu gehen, aus welchem Grund es bei deiner 470 nicht klappt.