FHEM App - Manage your Home

gvzdus · 12 April 2021, 21:52:05

Zitat von: jemu75 am 12 April 2021, 10:32:26
.... Auf der anderen Seite, muss zukünftig vermieden werden, dass jeder seine eigenen Templates baut und die Arbeit am Ende immer wieder gemacht wird. Es gibt aktuell zwei interessante Ansätze hierfür.
1) universelle Templates die, die verschiedenen Gerätearten unterstützen. (hierfür wäre eine Art Mapping nötig)
2) eine Bibliothek schaffen, in der jeder neue Templates einstellen kann und die jedem Nutzer von FHEMApp zugänglich ist

Ich habe heute mit meinem gebrochenen Javascript noch einmal überlegt, wie dieser Mapper aufgebaut sein könnte.
Ja, auch ich habe MAX-Thermostate, und das Template geht natürlich nicht, weil 2-3 Readings anders heißen.

Ich will nicht das "homebridgeMapping" von alexa - ich hasse jede neu erfundene Syntax.
Ich bin auf das hier gestoßen:

https://github.com/edudavid/json-map-transform

Wäre das eine "Mapper-Sprache", die allgemeintauglich ist? Ich würde das hilfsweise als Attribut "mapper" in "appOption" sehen: Das Mapper-Template wird geladen und jedes Event vom Device da durchgenudelt. Ein Kommando von fhemApp wird als Objekt "{ "action": "set pct 75" }" instanziert, durch den Mapper gejagt und dann wird "action" an FHEM geschickt.

Beispiel für das Device:

Code Auswählen

{ "template":"thermostat","room": "Buero","name": "Heizung Büro", "mapper": "thermostat_max" }

thermostat_max.json:

Code Auswählen

{
   "measured-temp": {
       "path": "temperature"
    },
   "pct": {
       "path": "valveposition"
    },
    "desired-temp": {
       "path": "desiredTemperature"
    }, ...
}

gvzdus · 12 April 2021, 21:59:20

Andererseits: So wild ist ein Template auch nicht. Und die Features sind ja ggf. unterschiedlich. Wir sollten uns dann nur auf eine Konvention einigen, wie z.B. "template_(shutter|switchWithKwh|switch|thermostat|...)_(max|shelly|hm|hmip|hue)", wobei die 3. Gruppe vorzugsweise der Modulname in Lowercase sein sollte.

P.S. Soll ich die Diskussion um
a) I8N
b) Mapping vs. Templates
mal wegforken in 2 neue Threads?

Vorschlag: Dort "Mehrheitsvotum" suchen, Veto natürlich bei Jens.

jemu75 · 12 April 2021, 22:05:25

Zitat von: gvzdus am 12 April 2021, 21:59:20
Andererseits: So wild ist ein Template auch nicht. Und die Features sind ja ggf. unterschiedlich. Wir sollten uns dann nur auf eine Konvention einigen, wie z.B. "template_(shutter|switchWithKwh|switch|thermostat|...)_(max|shelly|hm|hmip|hue)", wobei die 3. Gruppe vorzugsweise der Modulname in Lowercase sein sollte.

P.S. Soll ich die Diskussion um
a) I8N
b) Mapping vs. Templates
mal wegforken in 2 neue Threads?

Ja gern, wäre prima, wenn ich zu diesen beiden Themen Unterstützung bekomme. So könnte ich mich auf Bugfixes und weitere Features konzentrieren.

gvzdus · 12 April 2021, 22:47:16

Well, here it is:

Internationalization: https://forum.fhem.de/index.php/topic,120340.0.html
Multiple Device Support / Mapping: https://forum.fhem.de/index.php/topic,120341.0.html

@Jens: Wäre nett, wenn Du da mitliest.

Viele Grüße, Georg

jemu75 · 12 April 2021, 23:50:34

Zitat von: gvzdus am 12 April 2021, 22:47:16
Well, here it is:

Internationalization: https://forum.fhem.de/index.php/topic,120340.0.html
Multiple Device Support / Mapping: https://forum.fhem.de/index.php/topic,120341.0.html

@Jens: Wäre nett, wenn Du da mitliest.

Viele Grüße, Georg

Hallo Georg,

danke dir für die Erstellung der beiden Threads. Habe beide schon "abonniert" und werde die auf jeden Fall mit verfolgen.

Beste Grüße
Jens

jemu75 · 13 April 2021, 08:18:35

Zitat von: Icinger am 13 März 2021, 08:28:04
Könnte man dieses Verfahren nicht auch für das room- und group-Attribut nehmen?

lg, Stefan

Genau so funktioniert es.
Prio hat immer die Angabe innerhalb von appOptions. Dies gilt für name(alias), room, group und sortby.
Danach wird auf die jeweiligen FHEM-Attribute zugegriffen.
Für room, group und sortby kann man zusätzlich den Zugriff auf die FHEM-Attribute "blockieren". Dies geschieht über die config.json (siehe ignoreFhem...)

Beste Grüße
jens

jemu75 · 13 April 2021, 08:22:00

Folgende Anpassungen für den Slider werde ich mit dem nächsten Release freigeben.
1) linker und rechter Rand wird so verbreitert, dass er mit den "tastenbasierenden" Templates zusammen passt. (ist ne rein optische Geschichte)
2) der Slider reagiert auf die Farbvariable "success"
3) der Slider bekommt einen "Hint" der beim Verschieben den aktuellen Wert anzeigt.

Anbei schon mal eine kleine Vorschau, wie das dann aussehen wird.

binford6000 · 13 April 2021, 09:21:45

Zitat von: jemu75 am 13 April 2021, 08:22:00
Folgende Anpassungen für den Slider werde ich mit dem nächsten Release freigeben.
1) linker und rechter Rand wird so verbreitert, dass er mit den "tastenbasierenden" Templates zusammen passt. (ist ne rein optische Geschichte)
2) der Slider reagiert auf die Farbvariable "success"
3) der Slider bekommt einen "Hint" der beim Verschieben den aktuellen Wert anzeigt.

Anbei schon mal eine kleine Vorschau, wie das dann aussehen wird.

THX!

Wzut · 13 April 2021, 14:51:31

@jemu75 , was ist mit dem Sonosplayer Template passiert ? Auf deiner git Seite gibt es Screenshoots aber kein Template

Ich wollte mal schauen ob man das Sonos Template mit Anpassungen für den MPD verwenden kann.

tomspatz · 13 April 2021, 15:09:56

Zitat von: jemu75 am 13 April 2021, 08:22:00
Folgende Anpassungen für den Slider werde ich mit dem nächsten Release freigeben.
1) linker und rechter Rand wird so verbreitert, dass er mit den "tastenbasierenden" Templates zusammen passt. (ist ne rein optische Geschichte)
2) der Slider reagiert auf die Farbvariable "success"
3) der Slider bekommt einen "Hint" der beim Verschieben den aktuellen Wert anzeigt.

Anbei schon mal eine kleine Vorschau, wie das dann aussehen wird.

Moin Jens

wird der slider auch "halbe" Werte darstellen können?
Wir "sprachen" da mal drüber

Jamo · 13 April 2021, 15:40:43

Zitat von: jemu75 am 10 April 2021, 23:45:22
"...in der Regel auch, das ein Befehl nicht angekommen ist, dann clicke ich halt nochmal..." - Also das würde mich ja mega annerven. Hast du schon mal auf nen Lichtschalter gedrückt und das Licht geht erst beim zweiten Mal an.
In deinem FHEM-Log steht ja "...For details see the crsfToken..." Bekommst du da evtl. noch was genaueres zu raus?
Weiterhin würde mir folgendes helfen. Schalte mal den DebugMode ein und schau mal ob im syslog von FHEMApp Fehler auftauchen.

Hallo Jens,
ich habe die Ursache für den csrf error im Log gefunden: Ich sitze am iPAD, und habe immer den fhemapp Homescreen geöffnet, mit meinen wichtigsten Bedienelementen, um irgendwas zu schalten eben.
Wenn ich dann nach einiger Zeit das iPad wieder aus dem Screenlock hole, und dann auf dem fhemapp Homescreen einen Schalter betätige, ist oben rechts der Punkt noch für etwa 3 Sekunden rot, weil die Verbindung wohl noch nicht da ist. Und genau dann bekomme ich diese Fehlermeldungen. Und dann muss ich eben noch ein zweites mal drücken.

Wenn ich abwarte bis oben rechts grün ist, ist alles OK. Also sitzt der Fehler vor dem iPad, ich bin einfach zu schnell

Code Auswählen

021.04.10 10:30:26 3: FHEMWEB WEB CSRF error:  ne abcdefghijklmnopqrs for client WEB_MEI.NE.IP.AD_58127 / command jsonlist2 WLANg. For details see the csrfToken FHEMWEB attribute.

jemu75 · 13 April 2021, 16:25:21

Zitat von: Jamo am 13 April 2021, 15:40:43
Hallo Jens,
ich habe die Ursache für den csrf error im Log gefunden: Ich sitze am iPAD, und habe immer den fhemapp Homescreen geöffnet, mit meinen wichtigsten Bedienelementen, um irgendwas zu schalten eben.
Wenn ich dann nach einiger Zeit das iPad wieder aus dem Screenlock hole, und dann auf dem fhemapp Homescreen einen Schalter betätige, ist oben rechts der Punkt noch für etwa 3 Sekunden rot, weil die Verbindung wohl noch nicht da ist. Und genau dann bekomme ich diese Fehlermeldungen. Und dann muss ich eben noch ein zweites mal drücken.

Wenn ich abwarte bis oben rechts grün ist, ist alles OK. Also sitzt der Fehler vor dem iPad, ich bin einfach zu schnell

Code Auswählen Erweitern
021.04.10 10:30:26 3: FHEMWEB WEB CSRF error: ne abcdefghijklmnopqrs for client WEB_MEI.NE.IP.AD_58127 / command jsonlist2 WLANg. For details see the csrfToken FHEMWEB attribute.

Naja, das zählt eher zu den Punkten die ich optimieren muss. Nach dem "Aufwachen" aus dem Screenlock muss die App faktisch keine 3 Sekunden warten, sondern kann sofort neu Verbinden. Die 3 Sekunden sind eigentlich die Pause zwischen Verbindungsabbruch und nächstem Versuch neu zu verbinden. Auf jeden Fall vielen Dank fürs Testen. Jetzt weiß ich woher der Fehler kommt.

binford6000 · 13 April 2021, 19:41:06

Zitat von: Wzut am 13 April 2021, 14:51:31
@jemu75 , was ist mit dem Sonosplayer Template passiert ? Auf deiner git Seite gibt es Screenshoots aber kein Template
Ich wollte mal schauen ob man das Sonos Template mit Anpassungen für den MPD verwenden kann.

Und ich würde mich mal an einer Anpassung für sonos2mqtt versuchen wollen

VG Sebastian

Benni · 13 April 2021, 20:59:53

Zitat von: Wzut am 13 April 2021, 14:51:31
@jemu75 , was ist mit dem Sonosplayer Template passiert ? Auf deiner git Seite gibt es Screenshoots aber kein Template
Ich wollte mal schauen ob man das Sonos Template mit Anpassungen für den MPD verwenden kann.

Sonos ist kein Standard-Template, so wie auch Chart oder Sysmon!

Guckst du hier: https://github.com/jemu75/fhemApp/tree/master/src/components

gb#

jemu75 · 14 April 2021, 12:31:49

Zitat von: Benni am 13 April 2021, 20:59:53
Sonos ist kein Standard-Template, so wie auch Chart oder Sysmon!

Guckst du hier: https://github.com/jemu75/fhemApp/tree/master/src/components

gb#

Oh, da hat Benni aber tief in die Trickkiste (Verzeichnisstruktur) gegriffen.

Aber er hat Recht. Sonos ist kein Standard-Template, da es an einigen Stellen vom Layout des Standard-Templates abweicht. Bisher habe ich Sonos auch noch nicht in der Doku. Bin auch am Überlegen, ob ich das Sonos-Template generisch aufbaue und zu einem "Player-Template" mache. Aktuell sitze ich aber noch am Sysmon-Template.