ebusd.mqtt2.template: Fragen, Anregungen

[Reinhart]

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

Status01_0_name temp1
Status01_1_name temp1
Status01_2_name temp2
Status01_3_name temp1
Status01_4_name temp1
hier 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

[Reinhart]

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

[Beta-User]

@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

[Patrick131184]

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.

[rudolfkoenig]

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

.* LWT
  tele

Und da dieser Wert in die diversen Attribute so eingesetzt wird, fuehren die fehlenden \ zu Fehlermeldungen mit "Unknown command tele..."

[Beta-User]

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.

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.

Kannst Du bitte ein Beispiel geben, ich bin unsicher, ob ich das Problem begreife.

Also aus dem template-code

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

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

Code Auswählen Erweitern

m,[^:]+:([^/]+)[/].*:.*$,
an den Start gehen?

[rudolfkoenig]

Ist das verständlich erklärt?

Ja.

mich selbst stört das eigentlich gar nicht so

Mich auch nicht, ich empfehle "lassen wie es ist"

m,[^:]+:([^/]+)[/].*:.*$,

Geht genausowenig.
Um zu helfen, muesste ich verstehen, was man will.

[Beta-User]

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

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?

[rudolfkoenig]

Hmm, 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".

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?

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.

[FunkOdyssey]

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.

[john30]

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 erreichen, hätte aber den Nachteil, dass sämtliche Topics bis zum nächsten Update quasi festgeschrieben sind.

[Beta-User]

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?

[Reinhart]

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.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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?

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[john30]

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

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

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

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

"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

[john30]

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?

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

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"