ebusd.mqtt2.template: Fragen, Anregungen

[Beta-User]

/set erwartet derzeit das gleiche Format wie ebusctl, also wäre richtig:

Code Auswählen Erweitern

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

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

[john30]

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.

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.

[Beta-User]

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

[Reinhart]

/set erwartet derzeit das gleiche Format wie ebusctl, also wäre richtig:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[Beta-User]

Hmm, kannst du mal versuchen, das in einfache Anführungszeichen zu packen? Also

Code Auswählen Erweitern

set ebusMQTT publish ebusd/430/ccTimer.Monday/set '06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr'
oder

Code Auswählen Erweitern

set ebusMQTT publish ebusd/430/ccTimer.Monday/set '"06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr"'

[john30]

Code Auswählen Erweitern

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

[Reinhart]

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

Code Auswählen Erweitern

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

[rudolfkoenig]

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

[Reinhart]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[rudolfkoenig]

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.

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.

[Reinhart]

@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

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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

Code Auswählen Erweitern

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

[john30]

Konsolenbefehl

Code Auswählen Erweitern

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.

Code Auswählen Erweitern


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.

[Reinhart]

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

Code Auswählen Erweitern

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

[TomLee]

@Reinhart

Wo hast du den das Template hinterlegt ? hier ist es nicht dabei.

edit:

doch ist dabei, hatte ein vorheriges mqtt2.ebus-1.template nach AttrTemplate geschoben.

[Beta-User]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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?