ebusd.mqtt2.template: Fragen, Anregungen

[rob]

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
Und wenn es der V2.x ist, dann dieser https://forum.fhem.de/index.php/topic,84636.msg769462.html#msg769462

VG
rob

[TomLee]

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.

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.

[TomLee]

Vermutlich, ich schreibe bisher nix, sind es die doppelten Semikolon, es wird nur eins erwartet, denk ich.

[TomLee]

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

[TomLee]

Schau im Traffic Monitor des MQTT2-Server, was wie gesendet wurde.

[TomLee]

Und ?

Wird das jetzt übernommen oder kommt es zu der Meldung von oben:

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

[TomLee]

Code Auswählen Erweitern

ReadingsVal("TimeSo","HHMM1su",0) vs.

Code Auswählen Erweitern

ReadingsVal("TimeSu","HHMM1su",0)
und als Ersatzwert würd ich bei ReadingsVal einen String verwenden bspw "00:00" "-:-"

[beaune]

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:

Hallo,

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.

[TomLee]

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

Code Auswählen Erweitern

{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):

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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: -:-;-:-;-:-;-:-;-:-;-:-;selected

Direkt am MQTT2_Server:

Code Auswählen Erweitern

set MQTT2_Server publish ebusd/700/hwcTimer.Monday/set 00:10;-:-;-:-;-:-;-:-;-:-;selectedTraffic-Monitor:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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;-:-;-:-;-:-;-:-;-:-;selected
Eine weitere Variante, alternativ zu der aus dem Template:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

00: ERR: invalid position
bei Dir nicht einfach ignorieren kann und die Werte doch übernommen werden ?
Es findet bei dir doch ein schreiben statt?

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

00: ERR: invalid position führt.

Evtl. hat es etwas damit zu tun was er hier unten schon erwähnt hat, trotz das es damals um eine 430 ging.

[TomLee]

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:

Code Auswählen Erweitern

hcTimerMonday:textField ebusd/470/ccTimer\x2eMonday/set $EVTPART1den setter hcTimerMonday wählen und in dem Textfeld dahinter dann die Zeiten eintragen, bspw.:

Code Auswählen Erweitern

04:20;09:00;11:00;20:00;-:-;-:-;selected
Was steht dann im ebusd-Log ?

[TomLee]

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