FHEM Wdget (iOS)

[Moeti]

Hallo!

Wenn ich für fhem_widget_command {"allowed_values":["unlocked","locked"]} eintrage, dann zeigt er zwar den richtigen Status an, aber der Keymatic lässt sich nicht schalten, da die Befehle "lock" und "unlock" lauten.
Deshalb hatte ich {"allowed_values":["unlock","lock"]} eingetragen, was zwar die Bedienung des Schlosses ermöglicht, aber eben keine korrekte Statusanzeige. Wie lassen sich Anzeigestatus und abzusetzender Befehl kombinieren?

lG
Moeti

[chris1284]

ich würde mir wünschen das beim setzen von zb werten an thermostaten eine verzögerung eingebaut wird.

wenn ich zb

Code Auswählen Erweitern

{"controlled_attribute":"desired-temp","allowed_values":["16.0","17.0","18.0","22.5","24.0"]}
definiert habe sendet die app beim schalten von 16 auf 24 bei jedem drücken von "+" den set-befehl.
das bombardiert fhem befehlen undd gff sendet man unnötig viel. so wird aus einem notwendigen befehl 4 befehle
andere frontends haben hier auch eine verzögerung um auch nur das zu sendne was notwendig ist (die desired-temp wenn nach zb 1,5 sek keine eingabe mehr erfolgte).

[HaPeRiebmann]

Hi

@Moeti: Spontan würde mir hier ein Workaround mit einem Dummy einfallen, der nur den state "lock" und "unlock" kennt. Dahinter eine Logik, welche den State analog zu deinem Keymatik schaltet und den Status wiederum auf "lock" und "unlock" mappt. Das könntest du über ein notify machen. Dummy state wechselt zu lock -> keymatik auf lock -> Keymatik wechselt auf locked -> Dummy auf lock. Selbes für unlock. Dann macht dein Signal in FHEM einen Roundtrip. Das kann man auch noch ein wenig eleganter machen

@chris1284: Genau so ist es umgesetzt, allerdings mit 400ms Latenzzeit. Das heißt, wenn du schneller tippst dann unterdrückt er die Signale bis du 400ms nichts mehr machst.

VG
Michael

[netwalk]

@HaPeRiebmann

Ich habe es mittlerweile geändert. Nun lasse ich mir im Widget ein dummy anzeigen, das den Wert der structure über ein notify erhält.

Vorher hatte ich etwas in der Art:

Code Auswählen Erweitern

define struct.fk.alle structure struct.state max.fk.eg.Badezimmer.1 max.fk.eg.Arbeitszimmer.1 max.fk.eg.Arbeitszimmer.2 ...
attr struct.fk.alle fhem_widget_command {"allowed_values":[],"order":0}

Nach Speichern und ggf. Restart fand sich das Attribut der structure auch bei den Mitgliedern wieder:

Code Auswählen Erweitern

attr max.fk.eg.Badezimmer.1 fhem_widget_command {"allowed_values":[],"order":0}

Diese wurden dann natürlich auch im Widget angezeigt, was ich nicht will.
War seltsam. Hat das mit Mechanismen der structure zu tun?


Eine andere Frage habe ich noch: ist die Anzahl der darstellbaren Zeilen im Widget durch Apple oder durch die App begrenzt? Ich glaube, bei etwa 12 oder 13 Zeilen wird abgeschnitten...

Und einen Vorschlag hätte ich auch noch: es wäre schön, wenn man Trennlinien oder kleine Abstände einfügen könnte, das steigert die Lesbarkeit. Als Workaround lasse ich mir einen dummy mit

Code Auswählen Erweitern

define dm.trenner.1 dummy
attr dm.trenner.1 alias .
...
set dm.trenner.1 .
anzeigen, ist aber nicht sooo toll...

[chris1284]

@chris1284: Genau so ist es umgesetzt, allerdings mit 400ms Latenzzeit. Das heißt, wenn du schneller tippst dann unterdrückt er die Signale bis du 400ms nichts mehr machst.

ah ok. wäre nicht schlecht wenn man das in den optionen selbst einstellen kann denn 400ms ist qausi bei mir jeder klick (wer kann so schnell auf nem futzeligen handy klicken um darunter zu bleiben  )

die app schmiert übrigens ab wenn am device sachen gestellt sind die nicht im attribut nicht gesetzt sind...

Code Auswählen Erweitern

fhem_widget_command {"controlled_attribute":"desired-temp","allowed_values":["16.0","18.0","20.0","22.0"]}

mein rt steht aktuell auf 17.0 und wenn ich uf -/+ klicke schmiert die app

[HaPeRiebmann]

Hi

@netwalk: Ja die Anzahl der Zeilen ist von Apple beschränkt. Die Maximale Höhe scheint exakt eine Bildschirmhöhe zu sein, sodass ein Widget maximal einmal Fullscreen werden darf.
Zu den Mechanismen der Structure kann ich dir leider nix gesichertes sagen. Das mit den Trennern hab ich mir ehrlich gesagt noch nicht überlegt. Ich könnte aber beispielsweise Gruppen einführen. Vielleicht das group Attribut nutzen oder einen neuen Wert im JSON definieren oder Räume nutzen... Gute Idee eigentlich.

Meinungen von den anderen?

@chris1284: Das mit den dicken Daumen ist mir neu . Ich musste hier einen Tradeoff finden zwischen schnellem Drücken und flotter Bedienung. Üblicherweise nimmt man da was um die 400ms. Ich setz es in der nächsten Version einfach mal höher.
Das Abschmieren der App hab ich auch festgestellt. Kurze Erklärung: Ich will mit dem Widget möglichst generisch bleiben. In den allowed_values dürfen deswegen alle Datentypen drin stehen, auch gemischt, was das primäre Problem ist. Deswegen abstrahiere ich hier alles als String und benutze es intern auch als String. Ich kann Fälle abfangen, wenn der Wert auf beispielsweise 17.5 steht, im Array aber nur 17 und 18 vorkommen. Wenn zwischen drin ganze Zahlen fehlen kann ich damit noch nicht umgehen.
Dass das Widget abschmiert hab ich zwar eigentlich abgefangen, scheint aber manchmal schief zu laufen.
Dieses Problem zu lösen ist grad eine meiner Baustellen. Bin aber noch auf keinen grünen Zweig gekommen.

VG
Michael

[chris1284]

in der tui sind zb default 500ms gesetzt womit bisher alles sehr gut klarkommen (konfigurierbar wie da wäre natürlich  top )

[HaPeRiebmann]

Hallo zusammen,

ich würde gern das eine oder andere experimentelle Feature in die App einbauen. Nur zum Spaß, ohne Langfristverpflichtung und basierend auf eurem Feedback. Deswegen hier mal die Frage:

Wer hat Bedarf an einem Pushservice auf die App?

Ich stelle mir das so vor: Apple stellt den APNS (Apple Push Notification Service) zur Verfügung. Bei diesem können sich Apps anmelden und bekommen einen eindeutigen Token. Diesen Token müsst ihr euch in eurem System speichern. Dazu müsst ihr eine Schnittstelle in die App eintragen die diesen entgegen nimmt und wiederum eurem FHEM zur Verfügung stellt. Das kann beispielsweise ein FHEM Modul sein, das ein GET Interface besitzt.

Wenn ihr nun von eurem FHEM eine Push Nachricht schicken wollt müsst ihr meinen Webservice mit dem Token eurer App(s) aufrufen und voilà. Push.

Anwendung wäre beispielsweise:
- Gewitter zieht auf, FHEM fragt euch ob ihr das Fenster schließen wollt
- Innentemperatur sinkt unter X Grad, FHEM fragt euch ob ihr die Heizung hochdrehen wollt
-...

VG
Michael

[Moeti]

Derzeit hab ich das mit PushOver umgesetzt.
Aber das in einer App zusammenzuführen, macht auch Sinn!

Darf ich einen Wunsch für eine zukünftige Version des Widget äußern: Vielleicht könnte man zusätzlich zu den allowed_values auch die commands im Attribut festlegen (zB für Keymatic, aber auch für andere Devices).

Danke
lG
Moeti

[HaPeRiebmann]

Kannst du das nicht mit controlled_attribute machen?
Kannst mal ein Beispiel schreiben?

[Moeti]

Hallo!

Da ich hier keine Attribute verändern muss, weiß ich nicht, was ich mit "controlles_attribute" anstellen sollte.

Falls zwei "allowed_values" eingetragen sind und im Widget daher ein Schalter angezeigt wird, so schicked dein Widget offenbar immer den anderen Wert mit "set" an FHEM, falls er betätigt wird.

In meinem Fall habe ich für mein Keymatic fhem_widget_command {"allowed_values":["locked","unlocked"]} eingetragen. Betätige ich im Zustand "locked" den Schalter, so setzte das Widget den Befehl "set DEVICE unlocked" ab (und umgekehrt). Dieses Kommando kennt das Device aber nicht, es müsste "unlock" heißen. D.h. die Bezeichnung des Device-Staus ist nicht ident mit dem entsprechenden Kommando.

Mit dem von dir vorgeschlagenen Workaround mit "notify" bin ich nicht weitergekommen, aber ich habe es dann mit dem Attribut "eventMap" geschafft, sodass die ungültigen Befehle in gültige umgesetzt werden.

Daher sieht meine Definition für die Keymatic folgendermaßen aus:

Code Auswählen Erweitern

define SH_Tuerschloss CUL_HM XXXXXX
attr SH_Tuerschloss fhem_widget_command {"allowed_values":["locked","unlocked"]}
attr SH_Tuerschloss eventMap lock:locked unlock:unlocked

Damit zeigt das Widget den aktuellen Status richtig an und lässt sich auch entsprechend schalten.
Ob ich allerdings alle Zustände mit "uncertain" abgedeckt habe, weiß ich noch nicht.

lG
Michael

[HaPeRiebmann]

Hi,

du hast recht, das Widget sagt immer

Code Auswählen Erweitern

set [devicename] [allowed_value]
wenn du aber ein controlled_attribute setzt dann macht es

Code Auswählen Erweitern

set [devicename] [controlled_attribute] [allowed_value]
und zeigt auch den Status dieses Attributes an. Das könnte doch das sein was du meinst.

schau mal in die Instructions.
http://www.tasior.de/FHEM_Widget/

VG

[kvo1]

überlege grade ob ich  mir das "gönnen" sollte, klingt so nicht schlecht !

[shorty81]

würde gerne Max-Thermostate einbinden.
tauchen aber mit {"controlled_attribute":"desired-temp","allowed_values":["16.0","17.0","18.0","22.0","24.0"]} überhaupt nicht auf?
Was kann ich tun?

VG
Chris

[HaPeRiebmann]

Hi Chris,

Kannst mal den Part in deiner fhem.cfg anhängen?