ebusd.mqtt2.template: Fragen, Anregungen

[Reinhart]

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.

Code Auswählen Erweitern

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 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

[Beta-User]

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...

[Reinhart]

bei nur belegten Werten sieht die Abfrage so aus:

Code Auswählen Erweitern

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

[Beta-User]

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?

[Reinhart]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[Reinhart]

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

[Beta-User]

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.

[Reinhart]

ich bin dem Fehler schon auf der Spur, wenn ich den 2.Befehl aus der setList entferne (Warmwasser) funktioniert es.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[Beta-User]

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...

[Reinhart]

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.

Code Auswählen Erweitern

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

[Beta-User]

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?

[Patrick131184]

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

[john30]

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?

[Patrick131184]

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


Die zu definierenden Zeiten kann man hier, entsprechend des Wochentages, setzen.

Code Auswählen Erweitern

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

[Beta-User]

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.

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?

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...