Hallo,
ich habe wahrscheinlich falsch gesucht, ich möchte Text an eine Funktion eines Geräts senden, ist das möglich?
Mehrere Beispiele:
Wie kann man das machen?
Danke
Das ist im Moment nicht möglich, aber es gibt eine Anfrage, für die du abstimmen kannst.
Aktuelle Lösung… Über node-red konvertieren!
OK, ich habe gerade abgestimmt, aber wir sind nur zu zweit 
Ich kenne node-red überhaupt nicht, ich verwende bash und mosquitto für den MQTT-Austausch.
Danke
@pierre-gilles hatte ein tolles Video über node-red gemacht:
Es gibt auch eine MQTT-API…
Du kannst dann direkt das Topic deines Buttons auf dem betreffenden Gerät „abhören“.
Ich werde mir das ansehen müssen, aber das bedeutet, dass nur noch node-red für die MQTT-Verwaltung nutzbar ist, Python und Bash sind also nicht mehr wirklich kompatibel…
Ich habe gerade mehrere Tage an dem Thema gearbeitet, um das System in Bash zu verstehen und zum Laufen zu bringen…
EDIT: Gilt das Problem auch für die Daten?
Also habe ich die 2 Links angesehen, aber nirgends wird das Senden von Text oder etwas anderem erwähnt…
Wenn ich versuche, etwas zu senden, wird der Wert des Geräts nicht aktualisiert…
ob es nun über mosquitto oder über node-red geschieht.
Kann mir jemand bitte weiterhelfen?
Hattest du dieses Tutorial gesehen @Hizo?
Ich nehme an, du hast dein Problem inzwischen dank deines Tutorials gelöst?
Ja, zum Glück gibt es Dokumentation 
Ich hatte ein bisschen Schwierigkeiten, alles zu verstehen, aber jetzt ist es okay.
Aber mein Problem bleibt bestehen…
Wie kann ich Text senden und in Gladys anzeigen?
Senden, kein Problem über MQTT, das funktioniert.
Aber es ist unmöglich, den Text in Gladys anzuzeigen.
Muss ich eine spezielle Gerätefunktion verwenden, die Text akzeptiert?
Ich verheimliche nicht, dass mich das gerade frustriert, um mein TUTORIAL über Asiprateur <=> BASH <=> GLADYS abzuschließen
Das ist das einzige blockierende Element.
Ich habe es in BASH und mit Node-RED getestet.
Im letzteren Fall habe ich einfach eine msg.payload im String-Format in eine MQTT-Funktionalität injiziert und dieselbe Funktionalität als Eingabe mit einem Debug.
Wenn ich den Text sende, sieht man seine Ankunft im Debug.
Also funktioniert alles auf MQTT-Ebene.
Aber wie kann ich ihn in Gladys anzeigen…
Danke für deine Arbeit.
Das ist nicht möglich @Hizo, Text in Gladys zu speichern.
Also… ich weiß nicht, was ich davon halten soll…
Ein Informationsanzeigesystem, das keinen Text anzeigen kann? 
Ich weiß nicht, wie Gladys funktioniert, aber warum? Wie?
Da ich hauptsächlich Sprachen ohne typisierte Variablen verwende, ist mir das unbegreiflich.
Denn es ist möglich, Text in int zu casten, wenn nötig, wer mehr kann, kann auch weniger.
Warum nicht einfach nur Text verwenden, anstatt Zahlen?
Liegt das an Gladys? An MQTT? Oder anderen Elementen?
Ist es nicht möglich, „einfach“ eine Funktion zu erstellen, die einfach anzeigt, was man ihr gibt?
Danke, dass du mir das erklärst
Ich habe dir auf der anderen Seite geantwortet 
Die Daten sind in der Datenbank typisiert, es sind digitale Daten. Daher ist es heute nicht möglich.
OK, die Typisierung der DB erklärt die Einschränkung.
Daher ist Gladys zwar benutzerfreundlich, aber überhaupt nicht entwicklerfreundlich.
Denn es ist unmöglich, zum Beispiel eine benutzerdefinierte Nachricht anzuzeigen, sei es eine Informations- oder Fehlermeldung.
Für jeden Text muss der Quellcode von Gladys geändert werden, was extrem aufwendig und komplex ist, wenn man ständig Zeit damit verbringen muss, Konstanten zu definieren, denn dafür braucht man die Kompetenz, die Zeit, um es zu tun, die Zeit, um es zu testen, alles in die Produktion zu bringen… und die Zustimmung der Gruppe für jede Änderung…
Daher ist es unmöglich, in einer Ecke sein eigenes kleines Ding zu entwickeln
Das schreckt mich total ab 
Aus meiner kleinen Sicht als kleiner Entwickler müsste man entweder:
Wenn es zu kompliziert ist, wird das die kleinen Entwickler nicht motivieren, mitzumachen.
Letztlich ist das nur meine Meinung.
Danke an alle, die meinen Post unterstützen, ich fühle mich nicht mehr so allein 
@pierre-gilles
Glaubst du, dass es eine Lösung für dieses Problem geben könnte, die die Tür zu vielen Möglichkeiten öffnen könnte (aus meiner Sicht).
Nichts ist unmöglich, aber für deinen Staubsaugerfall denke ich nicht, dass dies die Lösung ist. Wir können durchaus einen nativen Staubsauger-Typ in Gladys erstellen.
Übrigens, bei deinem Staubsauger verstehe ich nicht, was dich aktuell blockiert. Welche Funktion fehlt dir in Gladys (Funktion im Sinne von Gladys)?
Kannst du mir funktional (ohne technische Details) beschreiben, was du mit diesem Staubsauger erreichen möchtest?
Danke für dein Engagement
Ich denke, die Möglichkeit, Text anzuzeigen, geht weit über meinen spezifischen Nutzen für diesen Staubsauger hinaus.
Ideen:
All das einfach über MQTT vom Entwickler umgesetzt und ohne den Quellcode von Gladys anpassen zu müssen, denn:
Letztlich denke ich, dass man so weitermachen sollte, wie ihr es tut, Konstanten für Werte, aber es sollte eine Funktion „Text“ geben, mit der man den gewünschten Text anzeigen kann.
Auf diese Weise kann man, wenn es sich um einen spezifischen Text handelt, ihn anzeigen, und wenn es sich um einen Text handelt, der in eine Konstante gesetzt werden kann, kann man ihn anzeigen, bis die Konstanten und Funktionen erstellt sind.
Denn ja, es ist schöner, die richtige Funktion mit ihrer Einheit und ihrem Symbol zu verwenden.
Um noch weiter zu gehen, müsste man auch die Möglichkeit entwickeln, einen Textwert im Auslöser der Szene „Gerätestatusänderung“ und „Nur fortsetzen, wenn“ zu verwenden.
Und das Beste wäre, die Möglichkeit zu haben, das Symbol anzupassen (ja, ich bin bis zum Ende nervig ).
Mein Standpunkt ist, dass man eine einfache Möglichkeit belassen sollte, das anzuzeigen, was man möchte, damit jeder Baby-Dev seine kleinen persönlichen Skripte autonom erstellen kann.
Um zu meinem Staubsauger zurückzukehren, hier sind die Informationen, die er mir geben kann:
Zustände, die in Gladys-Konstanten definiert werden könnten:
Wert ‹ docked › im Topic ‹ state:state ›.
Wert ‹ medium › im Topic ‹ state:fan_speed ›.
Wert ‹ Charging › im Topic ‹ attributes:valetudo_state.name ›.
Wert ‹ stop › im Topic ‹ command_status:command ›.
Wert ‹ state › im Topic ‹ config:schema ›.
Wert ‹ ok › im Topic ‹ command_status:message ›.
→ Diese Werte können global OK sein, erfordern aber das Verwalten aller Werte und das Überprüfen der Übereinstimmung mit anderen Staubsaugern. Die Werte könnten möglicherweise von den Staubsaugern und der Software abhängen…
Spezifischere Nachricht, bei der man alle Möglichkeiten finden müsste:
Wert ‹ No error › im Topic ‹ attributes:last_run_stats.errorDescription ›.
→ Ich denke, das ist viel spezifischer für meinen Staubsauger.
Wirklich spezifische Werte für meinen Staubsauger:
Wert ‹ rockrobo › im Topic ‹ config:name ›.
Wert ‹ rockrobo › im Topic ‹ config:unique_id ›.
Wert ‹ Roborock › im Topic ‹ config:device.manufacturer ›.
Wert ‹ roborock.vacuum.s5 › im Topic ‹ config:device.model ›.
Wert ‹ rockrobo › im Topic ‹ config:device.name ›.
Wert ‹ rockrobo › im Topic ‹ config:device.identifiers ›.
Wert ‹ 0.10.9 › im Topic ‹ config:device.sw_version ›.
→ Das sind nur Texte, die man nicht in Konstanten setzen kann.
Hier gibt er die zu verwendenden Topics an, also spezifisch für die Software und ihre Konfiguration:
Wert ‹ valetudo/rockrobo/command › im Topic ‹ config:command_topic ›.
Wert ‹ valetudo/rockrobo/state › im Topic ‹ config:state_topic ›.
Wert ‹ valetudo/rockrobo/set_fan_speed › im Topic ‹ config:set_fan_speed_topic ›.
Wert ‹ valetudo/rockrobo/custom_command › im Topic ‹ config:send_command_topic ›.
Wert ‹ valetudo/rockrobo/attributes › im Topic ‹ config:json_attributes_topic ›.
→ Das sind nur Texte, die man nicht in Konstanten setzen kann.
Liste der möglichen Werte einiger Befehle:
Wert ‹ start:pause:stop:return_home:battery:status:locate:clean_spot:fan_speed:send_command › im Topic ‹ config:supported_features ›.
Wert ‹ min:medium:high:max:mop › im Topic ‹ config:fan_speed_list ›.
→ Könnte mehr oder weniger in Gladys gesetzt werden, hängt aber von den Fähigkeiten der Staubsauger ab.
Datumsverwaltung (Anzahl der Millisekunden seit dem 01/01/1970):
Wert ‹ 1676655003668 › im Topic ‹ command_status:updated ›.
Wert ‹ 1676655000000 › im Topic ‹ attributes:last_run_stats.startTime ›.
Wert ‹ 1676655003000 › im Topic ‹ attributes:last_run_stats.endTime ›.
→ Selbst wenn ich das Datum berechne, kann ich es nicht in Gladys anzeigen.
→ Noch eine Idee für eine zu entwickelnde Funktion
Letztlich erfordert das Entwicklung auf eurer Seite, obwohl alles über eine Textfunktion laufen könnte.
Ich schätze Gladys wirklich, sein Design, seine Benutzerfreundlichkeit…
Deshalb bin ich nervig und denke, dass diese Art von generischer Funktion das Leben vereinfachen und dir helfen würde, keine Zeit mit spezifischeren Anforderungen (andere als meine, die natürlich priorisiert werden 
) zu verlieren.
Fazit: Danke dir und es lebe Gladys!
Das entspricht voll und ganz der Funktionsanfrage, die ich schon seit einiger Zeit gestellt habe!
Ok @Hizo, danke für deine sehr vollständige Rückmeldung, das ist sehr interessant!
Ich denke, dass es tatsächlich mehrere Rückmeldungen gibt, die separat behandelt werden können:
Zu diesem berühmten « text »-Typ, den du erwähnst, bin ich nicht gegen die Idee, eine Möglichkeit zu haben, benutzerdefinierte Texte in MQTT zu senden, aber ist das mit einem Gerät verbunden, da bin ich mir weniger sicher? (abzuwarten). Typischerweise, Geburtstage in der Box « Geräte im Raum » anzeigen, hat das Sinn? Nicht so sicher ^^
Die Philosophie des Projekts ist es, generische Geräte vorzuschlagen, damit das gesamte Gladys-Ökosystem um vordefinierte, generische Geräte herum funktioniert, ohne jegliche Codeanpassung, egal ob es sich um ein benutzerdefiniertes MQTT-Gerät handelt.
Dadurch sind wir in der Lage:
All das, ohne zu codieren!
Ich verstehe die Idee, verschiedene und vielfältige Informationen in Gladys hochzuladen, und es wäre mir ein Vergnügen, das zu haben, aber es sollte keine nativen Typen ersetzen.
Du bist nicht nervig, ich bin derjenige, der es ist, weil ich die Dinge richtig machen will, anstatt die einfache Lösung zu wählen
Im Gegenteil, ich denke, dass diese Art von Funktionen am Ende Zeit kosten wird, denn dann wird die Frage sein: Kann ich diese Funktion in den Szenen nicht steuern? Was ist mit Alexa? Und der Chat? usw…
Unser Management der nativen Funktionen ist recht einfach umzusetzen und spart meiner Meinung nach allen Zeit!
Ich werde einen erstellen.
Verwaltung eines Datentyps: Du bist nicht der Erste, der danach fragt, und tatsächlich hat das Sinn. Der Datentyp kann dann in der Kategorie „Robotersauger“ verwendet werden, um generische Features wie „Startdatum der letzten Reinigung/Enddatum“ zu haben.
Ja, das wäre ein generischer Bedarf, nicht nur auf Staubsauger beschränkt.
Fehlerbehandlung für Geräte: Wie kommuniziert man mit dem Benutzer, wenn ein Gerät ein Problem hat?
Vielleicht haben wir uns nicht verstanden, stell dir Szenen vor, die bei bestimmten Temperaturen oder anderen Bedürfnissen Informationen über MQTT senden, die von BASH (z. B.) erfasst werden, das ein Programm entsprechend ausführt, und wenn dieses abstürzt, könnte die Information über MQTT an Gladys zurückgemeldet werden.
Für diesen berühmten „text“-Typ, von dem du sprichst, bin ich nicht gegen die Idee, eine Möglichkeit zu haben, benutzerdefinierte Texte über MQTT zu senden, aber ist das mit einem Gerät verbunden, da bin ich mir weniger sicher? (abzuwarten). Typischerweise, Geburtstage in der Box „Geräte im Raum“ anzeigen, macht das Sinn? Nicht so sicher ^^
In der Tat, dieses Beispiel wäre nicht gut platziert, man müsste vielleicht eine spezielle Textbox sowie eine Gerätetextfunktion für die anderen Beispiele vorschlagen, die ich detailliert beschrieben habe (Version, Name des Roboters…).
Ich verstehe die Idee, verschiedene Informationen in Gladys hochzuladen, und es wäre mir ein Vergnügen, das zu haben, aber es sollte keine nativen Typen ersetzen.
Das wäre zusätzlich, aber meiner Meinung nach ein sehr großer Vorteil, der kleinen Entwicklern, die Gladys für sich anpassen wollen, viel Freiheit geben würde.
Im Gegenteil, ich denke, dass diese Art von Funktion am Ende Zeit kosten wird, denn dann wird die Frage sein: Kann ich diese Funktion in den Szenen nicht steuern? Was ist mit Alexa? Und der Chat? usw…
Es muss klar sein, dass es sich um Text handelt, der nicht exportierbar ist.
Aber die Szenen… das wäre cool, auch wenn ich im Moment keine Verwendung dafür habe
Unsere Verwaltung der nativen Funktionen ist recht einfach umzusetzen und spart meiner Meinung nach allen Zeit!
Gibt es dazu ein Tutorial?
Dafür haben wir bereits einen Mechanismus in Gladys, die „device_param“!
Die aktuelle Modellierung eines „device“ in Gladys:
(Siehe: Modélisation DB | Gladys Assistant )
Nein, kein Tutorial, ich stimme zu, dass es etwas besser dokumentiert werden sollte
Dafür gibt es bereits einen Mechanismus in Gladys, die „device_param“!
Und wie nutzt man die ohne die Datenbank zu verwenden?
Übrigens, ist die Datenbank überhaupt zugänglich?
Die Dokumentation ist super wichtig, wenn Leute Änderungen vorschlagen sollen.
Zum Beispiel, ich habe mir die REST-API angesehen und nirgends wird ein Schlüssel erwähnt.
Es scheint, dass dies nur für Gladys Plus verfügbar ist, aber das ist in der Dokumentation nicht angegeben.
