Ok, ich denke die Funktion ist hier anders gedacht und aufgebaut:
Im Feld "Nachricht" wird definiert, wie eine Nachricht (erstmal egal ob Alarm oder Status) aussieht. Die Nachricht kann "Klartext" enthalten sowie die im 2. Beitrag aufgeführten {}-Container. Nun gibt es zwei Sendeverfahren der Nachricht. Entweder ist der Trigger ein aktiver Alarm, in dem Fall wird die Nachricht so oft wiederholt, wie im Alarmintervall vorgegeben, bis alle Alarme deaktiviert sind. Der zweite Weg ist als Statusbericht. In dem Fall gibt es keinen Trigger, die Nachricht wird alle x Sekunden (Statusintervall) über die Laufzeit des Thermos gesendet. In beiden Fällen wird als Nachricht das geschickt, was im Feld "Nachricht" eingetragen ist. Der Container {alarme} umfasst alles, was in den Feldern "Über" und "Unter" aufgeführt ist. Der Container {statusse} umfasst alles was im Feld "Status" eingetragen ist. Wenn eine Nachricht also aus {alarme} und {statusse} besteht, dann werden sowohl bei einem Alarm, als auch bei einem "Statusbericht" alle aktiven Alarme und Statuswerte geschickt.
Demnach war mein Vorschlag, die Firmware standardmäßig mit einem {statusse} anstelle eines {alarme} zu versehen, auch nicht wirklich sinnvoll, weil dann bei einem Alarm nur der Statusbericht gesendet wird, aber nicht der Alarmtext, da lag ich also falsch.
Wenn ich dich richtig verstehe, dann hättest du bei einem Alarm gerne nur die Alarmwerte und bei einem Statusbericht einfach alle vorhandenen Temperaturen, ohne besonderen Hinweis auf einen Alarm. Ist das richtig? Das wird mit der bestehenden Funktion leider nicht funktionieren.
@EinBjoern falls ich falsch liege, korrigiere mich bitte.
[automerge]1531927865[/automerge]
Demnach ist auch das Hinzufügen von "disable_notification=true" für eine Nachricht ohne Ton nicht möglich. Ist mir auch gerade erst bewusst geworden. Gesendet wird immer das, was im Feld "Nachricht" definiert ist, egal ob über den "Alarmintervall" oder über den "Statusintervall".
