FHEM App - Manage your Home

[Jamo]

Hallo Jens,
erstmal nochmal dank für fhemapp, je mehr ich mich damit beschäftige, desto begeisterter bin ich. Wie in meiner vorherigen Antwort, habe ich jetzt auch das scene template benutzt - Alle deine Elemente sind für die Bedienung und einfache Handhabung optimiert, man versteht sofort was das Element macht. Alles sehr strukturiert und die gewünschte Funktion wird optisch durchdacht visualisiert, mit einem minimum an overhead. Klare, einfache Strukturen, kein Schnickschnack - HAMMER.

Nun, gibt es bei den appOptions auch die Möglichkeit, ein sortby mit anzugeben?
also attr appOptions { ...", "sortby": "12", ... }

Einfach weil ich in FHEM das sortby benutze, um die Elemente an mein FHEMWeb anzupassen, aber fuer's Handy, um einige wichtige Funktionen in fhemapp abzubilden bräuchte ich eine andere sortby Reihenfolge.

Das wäre dann equivalent zu ''group'' & ''room'' - Wenn nichts gesetzt, übernimmt fhemapp das sortby aus FHEM, ansonsten aus den appOptions. Das wäre rückwärtskompatibel und macht nichts kaputt.

[Jamo]

Wir sollten dem Jens langsame doch mal ein iPhone spendieren.
Bei der WetterApp wird im Desktop noch das Datum angezeigt, auf iPhone und iPad steht bei mir "invalid date".

[jemu75]

Hallo Jens,
erstmal nochmal dank für fhemapp, je mehr ich mich damit beschäftige, desto begeisterter bin ich. Wie in meiner vorherigen Antwort, habe ich jetzt auch das scene template benutzt - Alle deine Elemente sind für die Bedienung und einfache Handhabung optimiert, man versteht sofort was das Element macht. Alles sehr strukturiert und die gewünschte Funktion wird optisch durchdacht visualisiert, mit einem minimum an overhead. Klare, einfache Strukturen, kein Schnickschnack - HAMMER.

Nun, gibt es bei den appOptions auch die Möglichkeit, ein sortby mit anzugeben?
also attr appOptions { ...", "sortby": "12", ... }

Einfach weil ich in FHEM das sortby benutze, um die Elemente an mein FHEMWeb anzupassen, aber fuer's Handy, um einige wichtige Funktionen in fhemapp abzubilden bräuchte ich eine andere sortby Reihenfolge.

Das wäre dann equivalent zu ''group'' & ''room'' - Wenn nichts gesetzt, übernimmt fhemapp das sortby aus FHEM, ansonsten aus den appOptions. Das wäre rückwärtskompatibel und macht nichts kaputt.

Hallo Jamo,

vielen Dank für Dein positives Feedback.
Deine Idee das sortby mit in appOptions aufzunehmen kann ich gern umsetzen. Mich beschäftigt in dem Zusammenhang jedoch folgendes und das trifft übrigens auch auf room und group zu.
Wenn ich die die besagten Parameter in appOptions setze dann greifen diese. Das passt soweit. Wenn ich die Parameter nicht in appOptions setze, dann greifen bisher automatisch die Attribute von FHEM. Das ist aber nicht in jedem Fall gewünscht, wie man der Diskussion bzgl. room und group entnehmen kann. Es gab hierzu schon Vorschläge für room und group mit einer Art "hidden" zu arbeiten. Bei sortby sehe ich das Thema auch auf uns zukommen. 
Ich habe deshalb überlegt, ob es vielleicht sinnvoller ist, den automatischen "Fallback" auf die FHEM Attribute in der config.json als Option zu unterbinden. Das wäre auch eine Lösung, die ich persönlich besser finde.

In der config.json könnte das dann wie folgt aussehen:

Code Auswählen Erweitern


{
  "options": {
    "maxChartPoints": 100,
    "logBuffer": 500,
    "ignoreFhemGroups": true,
    "ignoreFhemRooms": true,
    "ignoreFhemSortby": true
  },
}


Wenn man diese Optionen setzt, dann werden die betreffenden FHEM Attribute ignoriert. Ansonsten gilt weiterhin der bisherige Mechanismus.
Deshalb die generelle Frage an alle: Was meint ihr dazu?

[Benni]

Im Zweifel einfach mal probieren und wenn es nicht geht, dann den connection Teil in der config.json  nutzen um auf den korrekten Server+Port+Pfad zu verweisen.
Intern schaut die App auf welchem Host+Port sie aufgerufen wurde und verwendet diese Verbindungsdaten. Nur wenn der connection Teil in der config.json eingetragen wurde, dann wird dieser verwendet.

Gezweifelt .... versucht .... funktioniert!

gb#

[jemu75]

Hier eine Lösung um für Roomate die Zustände 'home', 'gotosleep', 'asleep', 'awoken' und 'absent' über das Template 'scenes' einzustellen:

Einen dummy um das reading scene von den Lightscenes zu imitieren:

Code Auswählen Erweitern

defmod HomeStatus dummy
attr HomeStatus appOptions { "template": "scenes" }
attr HomeStatus readingList scene
attr HomeStatus setList scene:home,awoken,gotosleep,asleep,absent,gone
attr HomeStatus userReadings state {return ReadingsVal($name,'scene','nA')}

Einen cmdalias um den ''get'' zu implementieren

Code Auswählen Erweitern

defmod c_HomeStatus cmdalias get HomeStatus scenes AS {my $status = AttrVal('HomeStatus','setList','nA');;$status =~ s/scene://;;$status =~ s/,/\n/g;;return $status}

Das sieht dann so aus wie im Screenshot. Dann brauch man natuerlich noch ein notify um den Roommate zu informieren.

@jens: Unter dem 'gone' scheint noch eine Leerzeile zu sein, kann man die irgendwie wegmachhen?

Es gäbe aus meiner Sicht noch eine Alternative, ohne ein "dummy" zu erstellen. Man kann im Standard Template unter "main" die Parameter "leftMenu" oder "rightMenu" verwenden und damit rein optisch das gleiche Ergebnis, wie mit dem scenes Template erzielen.

Beispiel:

Code Auswählen Erweitern


  "main": [
    {
       "text": ["<definition für den aktuellen Status>"]
       "rightBtn": "mdi-dots-vertical",
      "rightMenu": ["erster Menüpunk:<erstes Kommando>","zweiter Menüpunk:<zweites Kommando>"]
    }
  ],



Das ganze ist auch in der Readme hier beschrieben.

[Jamo]

Deshalb die generelle Frage an alle: Was meint ihr dazu?

"Ja, gerne, guter Vorschlag" !

[Benni]

Ich habe deshalb überlegt, ob es vielleicht sinnvoller ist, den automatischen "Fallback" auf die FHEM Attribute in der config.json als Option zu unterbinden. Das wäre auch eine Lösung, die ich persönlich besser finde.

In der config.json könnte das dann wie folgt aussehen:

Code Auswählen Erweitern


{
  "options": {
    "maxChartPoints": 100,
    "logBuffer": 500,
    "ignoreFhemGroups": true,
    "ignoreFhemRooms": true,
    "ignoreFhemSortby": true
  },
}


Wenn man diese Optionen setzt, dann werden die betreffenden FHEM Attribute ignoriert. Ansonsten gilt weiterhin der bisherige Mechanismus.
Deshalb die generelle Frage an alle: Was meint ihr dazu?

Ich finde das eigentlich etwas zu pauschal!

Die "room": "hidden" (oder besser "room": "none") - Idee finde ich besser, da ich damit von Fall zu Fall, bzw. von Device zu Device die Möglichkeit hätte das Default-Verhalten abzuschalten.
"none" finde ich deswegen besser, weil a) nichts versteckt wird und b) um eine funktionale Verwechslung  mit dem aus FHEM bekannten hiddenroom zu vermeiden --> analog immer natürlich auch für "group").

Allerdings würde die pauschal-Variante die Konsequenz in der Anwendung von entweder Attributen oder appOptions erzwingen. Ein Mischbetrieb wäre somit per Definition ausgeschlossen.

... je länger ich darüber nachdenke, desto unentschlossener werde ich eher bin ich dafür!

gb#

[jemu75]

Ich kann's beweisen!

Hier ein List des device:

Code Auswählen Erweitern


Internals:
   DEF        6C6673
   FUUID      5eb96d1b-f33f-b8e7-aaaf-3a994940a006a827
   IODev      HMUART1
   LASTInputDev HMUART3
   MSGCNT     24
   NAME       OG.BU.SW.Licht
   NOTIFYDEV  global
   NR         957
   NTFY_ORDER 50-OG.BU.SW.Licht
   STATE      off
   TYPE       CUL_HM
   READINGS:
     2021-03-30 16:08:43   CommandAccepted yes
     2021-01-04 12:45:58   PairedTo        0x*****
     2021-03-19 04:57:03   R-pairCentral   0x*****
     2021-03-19 04:57:03   R-sign          off
     2019-05-23 18:08:38   RegL_00.        00:00 02:01 0A:23 0B:A8 0C:13 15:FF 18:00
     2019-05-23 18:08:39   RegL_01.        00:00 08:00 30:06 57:24
     2021-03-19 04:57:05   cfgState        ok
     2021-03-30 16:08:43   commState       CMDs_done
     2021-03-30 16:08:43   deviceMsg       off (to ccu)
     2021-03-30 16:08:43   level           0
     2021-03-30 16:08:43   pct             0
     2021-01-04 12:43:11   powerOn         2021-01-04 12:43:11
     2021-03-30 16:08:43   recentStateType ack
     2021-03-30 16:08:43   state           off
     2021-03-30 16:08:43   timedOn         off
     2021-03-30 16:08:43   trigLast        fhem:02
Attributes:
   IODev      HMUART1
   IOgrp      ccu:HMUART1
   alexaName  Büro
   alias      Büro Deckenlampe
   appOptions {
  "template": "switch"
}
   autoReadReg 0_off
   bbAlexaSmartHome 1
   devStateIcon on:15px-yellow off:15px-grey .*:15px-yellow
   event-on-change-reading .*
   expert     defReg,rawReg
   firmware   2.8
   group      Beleuchtung
   icon       light_ceiling_light
   model      HM-LC-SW1PBU-FM
   ogStructLichtAll OG.XX.ST.Licht.All
   peerIDs    00000000
   room       OG->Buero
   serialNr   QEQ0136***
   subType    switch
   userattr   ogStructLichtAll ogStructLichtAll_map structexclude
   webCmd     :


plus die Screenshots im Anhang!

Sehr geil... 
Das ganze kommt aber an Grenzen, wenn du z.B. den Raum "Wohnzimmer" einmal in "appOptions" definierst und in einem anderen Device das "Wohnzimmer" aus dem FHEM Attribut kommt.
Ich habe jetzt noch einen Vorschlag, um das Thema für alle zu lösen. Siehe mein Post weiter unten (Stichwort: config.json -> options -> ignoreFhemRoom usw.)
Gib gern mal deine Meinung dazu ab.

[jemu75]

Wir sollten dem Jens langsame doch mal ein iPhone spendieren.
Bei der WetterApp wird im Desktop noch das Datum angezeigt, auf iPhone und iPad steht bei mir "invalid date".
Screenshots anbei.

Hihi, bin mal gespannt wann es ankommt. 
Ich würde das Thema trotzdem gern lösen - notfalls auch ohne iPhone. Ich verwende intern die Javascript-Funktion toLocalString um die Zeitstempel aus FHEM zu formatieren.
diese Funktion ist meiner Meinung nach auch kompatibel mit Safari siehe
Welche iOS Version hast du im Einsatz?

[Jamo]

Welche iOS Version hast Du im Einsatz?

Bin auf iOS 14.5 Public Beta 4

[Jamo]

Es gäbe aus meiner Sicht noch eine Alternative, ohne ein "dummy" zu erstellen. Man kann im Standard Template unter "main" die Parameter "leftMenu" oder "rightMenu" verwenden und damit rein optisch das gleiche Ergebnis, wie mit dem scenes Template erzielen.

Beispiel:
Code: [Auswählen]
  "main": [
    {
       "text": ["<definition für den aktuellen Status>"]
       "rightBtn": "mdi-dots-vertical",
      "rightMenu": ["erster Menüpunk:<erstes Kommando>","zweiter Menüpunk:<zweites Kommando>"]
    }
  ],


Das ganze ist auch in der Readme hier beschrieben.

Hier der Roomate dummy mit der Lösung von Jens:

Code Auswählen Erweitern

defmod HomeStatus dummy
attr HomeStatus appOptions { "template": "homestate", "home": "true","room": "Z", "group": "Z", "dashboard": "true" }

Code Auswählen Erweitern

"name": "homestate",
"author": "jemu75",
"date": "2021-03-21",
"status": {
"bar": ["state:home:100:success","state:awoken:75:success","state:gotosleep:75:success","state:asleep:50:success","state:absent:20:success","state:gone:0:error"]
},
"main": [
{
"text": ["state:: %s"],
"rightBtn": "mdi-dots-vertical",
"rightMenu": ["home:home","gotosleep:gotosleep","asleep:asleep","awoken:awoken","absent:absent","gone:gone"]
}
]
},


[jemu75]

neues Release v3.3.6
Bugfix
Template scenes -> setup in appOptions korrigiert und dokumentiert.

ACHTUNG: sichert bitte euren Ordner ../fhemapp/cfg/ bevor ihr das neue Release auf euren Web-Server kopiert und fügt das danach dort wieder ein. Ansonsten geht eure Grundkonfiguration und eigene Templates verloren.

Github der Link: https://github.com/jemu75/fhemApp

[Jamo]

Hallo Jens,
3.3.6 installiert - funktioniert!

Hattest Du das hier mal angesehen? Oder ist das aufwändig? Ich frage weil Du sonst immer alle fragen beantwortest, aber hierzu hatte ich nichts gesehen.

Meine Frage in Antwort #282: https://forum.fhem.de/index.php/topic,119470.msg1144406.html#msg1144406

[hydrotec]

Hallo Jens,

erst einmal ein Dankeschön für deine gelungene Arbeit.

RESPEKT 

Auch wenn es noch am Anfang steht, ist es wirklich sehr einfach Fhem mobil darzustellen.
Was mir am Besten gefällt, ist das man seine Fhem Landschaft fast eins zu eins übernehmen kann.


Zwei Fragen hätte ich noch.
1.) Ist es geplant anstatt "FHEM-Devices vom Typ FileLog" auch auf den "Typ DbLog" wechseln zu können? (z.B. für die Charts)
2.) Besteht die Möglichkeit einem Device auch zwei Templates zuzuweisen? (z.B. switch zu Fritzbox Wlan/WlanGast)

Ansonsten noch viel Erfolg.
Gruß, Karsten

[Jamo]

Hallo Karsten,

2.) Besteht die Möglichkeit einem Device auch zwei Templates zuzuweisen? (z.B. switch zu Fritzbox Wlan/WlanGast)

Das schöne an Jens lösung ist dass das Ganze so schön Modular ist. 
Probier mal das template hier, Jens hatte schon gezeigt wie man eine 2-te Ebene (also z.B. einen 2-ten Schalter) bei den templates enablen kann.
Damit kannst Du oben rechts mit den kleinen Pfeilen zwischen wlan und guestwlan umschalten.

Damit hast Du unten im info Balken auch die Anzeige des Status WLAN / GuestWlan. Bei mir funktionerts damit.

Code Auswählen Erweitern

{
"name": "fbwlanswitch",
"author": "jemu75",
"date": "2021-03-21",
"status": {
"bar": ["box_wlan_5GHz:on:100:success","box_wlan_5GHz:off:0:success"]
},
"main": [
{
"leftBtn": "mdi-power-off",
"leftClick": ["state::wlan off"],
"text": ["box_wlan_5GHz:on:Wlan an","box_wlan_5GHz:off:Wlan aus"],
"rightBtn": "mdi-power-on",
"rightClick": ["state::wlan on"]
},
{
"leftBtn": "mdi-power-off",
"leftClick": ["state::guestWlan off"],
"text": ["box_guestWlan:on:GuestWlan an","box_guestWlan:off:GuestWlan aus"],
"rightBtn": "mdi-power-on",
"rightClick": ["state::guestWlan on"]
}
],
"info": {
"left1": ["box_wlan_5GHz:on::mdi-power-plug","box_wlan_5GHz:off::mdi-power-plug-off"],
"left2": ["box_wlan_5GHz:on: (Wlan on)","box_wlan_5GHz:off: (Wlan off)"],
"right1": ["box_wlan_5GHz:on::mdi-power-plug","box_wlan_5GHz:off::mdi-power-plug-off"],
"right2": ["box_guestWlan:on: (GuestWlan on)","box_guestWlan:off: (GuestWlan off)"]
}
}