FHEM App - Manage your Home

[Benni]

ähh ich blind ... wo finde ich etwas zum Thema Debugging ?

Ist schon ein par Seiten her: https://forum.fhem.de/index.php/topic,119470.msg1146987.html#msg1146987

gb#

PS: @Jens: Ich weiß, Doku macht keinen Spaß! Aber das sollte m.E. auch in die Doku auf github mit rein, ebenso wie der kleine connected-Crash-Kurs von gestern.

[Wzut]

@Benni, THX !

[jemu75]

Kann man so ein, per connected eingebundenes Device auch schalten?

Bisher nicht. Lässt sich aber leicht erweitern. Kommt auf die Todo Liste 

[Jamo]

Danke für dein sehr ausführliches Feedback insbesondere zur Performance. Da ist auf jeden Fall noch Luft nach oben
Zu den Ladezeiten - Es ist tatsächlich so, dass ich inzwischen alle Devices mit dem Attribut appOptions lade was sich leider negativ auf die Ladezeit auswirkt. Hintergrund ist das Handling von "room" und "group" Hier muss ich sowohl die FHEM Attribute als auch die in appOptions hinterlegten Parameter berücksichtigen. Da appOptions eine recht komplexe Struktur ist, kann man diese in FHEM nicht so einfach filtern. Mit den FHEM Attributen geht das deutlich besser.  Ich denke aber auch schon auf dem Thema rum, wie man das künftig besser lösen kann. Letztlich muss ich ja davon ausgehen, dass mal jemand 200 Devices via appOptions einbindet und das ganze auf nem kleinen  Raspi...

Weiterhin passiert bei Android folgendes. Wenn das Display ausgeht, dann wird im Hintergrund der websocket geschlossen. Der Reconnect erfolgt bisher mit einer fest eingebauten Verzögerung von 3 Sekunden. D.h. wenn ich das Smartphone wieder aktiviere, dann wird der websocket erst nach 3 Sekunden wieder geöffnet. Auch den Reconnect kann man sicher noch etwas "intelligenter" bauen.

Zum Thema Refreshbutton würde ich mal provokant fragen, wozu es den braucht. Ich habe die App so gebaut, dass immer alles aktuell sein sollte. Das ist aus meiner Sicht essentiell für "realtime" Anwendungen. Wenn das irgendwo nicht klappt, dann bitte unbedingt Bescheid geben. Bei dem Thema bin ich hartnäckig und das muss klappen - wenn nicht stampfe ich die App ein!  
Eine Ausnahme bildet die Änderung der Konfiguration (appOptions , Anpassungen der Template-Definitionen oder config.json). Hier ist ein Browser Reload nötig.

Hallo Jens,
wenn Du noch was an der Performance Schraube und Reconnect drehen könntest, das wäre auch meine erste Priorität, da würde ich mich freuen, dann machts einfach mehr Spass, wenn man nicht warten muss. Mir persönlich ist etwas zu langsam (usability). Und nicht jeder hat eine schnelle Maschine.

Bezüglich ReFreshbutton:
1) Ja, im Moment vor allem bei Konfigurationsänderungen. Für alle diejenigen, die anfangen, sich eine neue Konfiguration zusammenzustellen, ist das von Vorteil. Insbesondere habe ich mir unter iOS einen Schnellzugriff auf dem Homescreen erstellt, mit der iOS Browser Aktion 'add to Homescreen'. Damit bekommt man auf dem Homescreen ein Icon, das genau die fhemapp Homepage öffnet, aber OHNE die Browser-EingabeZeile oben und die Navigation unten (Vorteil: Mehr Platz auf dem Screen, und man muss nicht im Browser nochmal zu fhemapp hin-navigieren). Ich habe Dir mal 2 Screenshots angehängt, einmal der view mit dem Direktlink (erstes Bild) und einmal der Browser View (2-tes Bild). Beim Direktlink habe ich keinen reload button wie beim Browser view, und da muss man dann zweimal die Ansicht wechseln um manuell einen Reload zu erzwingen. Aber Direktlink ist eigentlich das was man haben will, eben einen direktlink auf sein Smarthome.

2) Realtime funktioniert par excellence, kann ich bestätigen. Aber Du weisst wie es ist: Wenn sich mal was nicht ändert, drückt man erstmal den Refresh Button, weil man denkt, die Änderung ist nicht angekommen. Sei es wegen einem re-connect, oder weil die VPN Verbindung noch nicht steht (Stichwort VPN-on-demand), oder bis man merkt das der event-on-change noch nicht gesetzt ist. Mit dem fehlenden Browser refresh von 1) ist das dann ein wenig viel hin- und her.

Ich weiss das ist alles ein wenig iOS spezifisch, aber ich habe mal gehört die Apple community sei grösser als die Android community

Bis dahin!

[Wzut]

so hier noch ein Template Vorschlag für die MAX! Fensterkontakte ohne das state Reading :

Code Auswählen Erweitern

{
  "name": "contact_max",
  "author": "Wzut",
  "date": "2021-04-11",
  "status": {
    "bar": ["onoff:1:100:success","onoff:0:0:success"],
    "error": []
  },
  "main": [
    {
      "text": ["onoff:1:open","onoff::closed"]
    }
  ],
  "info": {
    "left1": ["onoff:1::mdi-door-open","onoff:::mdi-door"],
    "mid1": ["windowOpen::%s:mdi-clock-start"],
    "right1": ["battery:ok::mdi-battery-90","battery:::mdi-battery-10"],
    "right2": ["rferror:1::mdi-wifi-off","rferror:::mdi-wifi"]
  }
}

@jemu75, zum angesprochnen Problem gestern : Wie man oben sieht geht das mit dem onoff und rferror Reading,
allerdings nur wenn man den Zustand 1 nach vorne nimmt und die mögliche 0 dann einfach weglässt ( ::: )

[tomspatz]

@Jamo
Würdest du mal den Code zeigen mit dem du die Anwesenheit anzeigst.

[jemu75]

Kann man so ein, per connected eingebundenes Device auch schalten?

Korrektur: das geht schon 

Solange dein set-Befehl nicht an eine Bedingung gebunden ist, die mittels <reading:wert> geprüft werden soll, kannst du das wie folgt machen.

Beispiel für mein Garagentor:

Code Auswählen Erweitern


{
  "name": "door",
  "author": "jemu75",
  "date": "2021-03-21",
  "status": {
    "bar": ["state:closed:100:success","state:open:0:success"],
    "error": ["Activity:^(?!alive):100:error:keine Verbindung","sabotageError:on:100:error:Fremdeingriff","cover:open:100:error:Fremdeingriff"]
  },
  "main": [
    {
      "text": ["state:closed:geschlossen","state:open:offen","state::%s"],
      "rightBtn": "mdi-unfold-more-horizontal",
      "rightClick": ["Connected.button.Internals.NAME::set %s on-for-timer 0.4"]
    }
  ],
  "info": {
    "left1": ["state:closed::mdi-garage-variant","state:open::mdi-garage-open-variant"],
    "mid1": ["Readings.trigger_cnt.Time::%t"],
    "right1": ["battery:ok::mdi-battery","battery:::mdi-battery-10"],
    "right2": ["Activity:alive::mdi-wifi","Activity:::mdi-wifi-off"]
  }
}


[Jamo]

@Jamo
Würdest du mal den Code zeigen mit dem du die Anwesenheit anzeigst.

Gerne: rr_jamo ist ein normales roomate device. Der nextRun für den Wecker ist über ein cmdalias realisiert.
Hier das appOptions attribute:

Code Auswählen Erweitern

attr rr_jame appOptions { "template": "homestate", "name": "Jamo", "home": true, "dashboard": true, "sortby": 1}

config.json template:

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": [
{
"rightBtn": "mdi-alarm-multiple",
"rightMenu": ["OFF:nextRun OFF","06.30:nextRun 06.30","06.40:nextRun 06.40","06.45:nextRun 06.45","06.50:nextRun 06.50","07.00:nextRun 07.00","07.10:nextRun 07.10","07.15:nextRun 07.15","07.20:nextRun 07.20","07.30:nextRun 07.30","07.40:nextRun 07.40","07.45:nextRun 07.45","07.50:nextRun 07.50","08.00:nextRun 08.00","08.10:nextRun 08.10","08.15:nextRun 08.15","08.20:nextRun 08.20","08.30:nextRun 08.30","08.40:nextRun 08.40","08.45:nextRun 08.45","08.50:nextRun 08.50"],
"text": ["fhemappState::%s"],
"leftBtn": "mdi-dots-vertical",
"leftMenu": ["home:home","gotosleep:gotosleep","asleep:asleep","awoken:awoken","absent:absent","gone:gone"]
}
],
"info": {
"left1": ["location:AtHome::mdi-home-circle-outline","location:::mdi-map-marker-check-outline"],
"left2": ["location:: %s"],
"right1": ["mood:Normal::mdi-emoticon-outline","mood:silent::mdi-sleep","mood:WFH::mdi-account-hard-hat"],
"right2": ["mood::%s"]
}
},

[jemu75]

so hier noch ein Template Vorschlag für die MAX! Fensterkontakte ohne das state Reading :

Code Auswählen Erweitern

{
  "name": "contact_max",
  "author": "Wzut",
  "date": "2021-04-11",
  "status": {
    "bar": ["onoff:1:100:success","onoff:0:0:success"],
    "error": []
  },
  "main": [
    {
      "text": ["onoff:1:open","onoff::closed"]
    }
  ],
  "info": {
    "left1": ["onoff:1::mdi-door-open","onoff:::mdi-door"],
    "mid1": ["windowOpen::%s:mdi-clock-start"],
    "right1": ["battery:ok::mdi-battery-90","battery:::mdi-battery-10"],
    "right2": ["rferror:1::mdi-wifi-off","rferror:::mdi-wifi"]
  }
}

@jemu75, zum angesprochnen Problem gestern : Wie man oben sieht geht das mit dem onoff und rferror Reading,
allerdings nur wenn man den Zustand 1 nach vorne nimmt und die mögliche 0 dann einfach weglässt ( ::: )

Also so richtig schlau werde ich aus dem Problem noch nicht. Gestern hast du in deinem Post folgenden Code gepostet.

Code Auswählen Erweitern


"right2": ["rferror:1::mdi-wifi-off","rferror:::mdi-wifi"]

Da hast du geschrieben, dass es nicht funktioniert. Heute zeigst du den selben Code und meinst es geht. 
Auf jeden Fall ist es richtig, dass bei Prüfung von Zahlenwerten der größte Wert immer links stehen muss, da die Wertzuweisungen von links nach rechts verarbeitet werden und Zahlenwerte auf "größer oder gleich" geprüft werden. Sobald eine Bedingung in den Wertzuweisungen zutrifft, werden alle weiteren Bedingungen ignoriert.

Beispiel wie es falsch definiert ist:

Code Auswählen Erweitern


["rferror:0:kein Fehler","rferror:1:Fehler"]


Beipiel wie es richtig definiert ist:

Code Auswählen Erweitern


["rferror:1:Fehler","rferror:0:kein Fehler"]


Im ersten Beispiel wird immer "kein Fehler" ausgegeben und die zweite Bedingung wird nie zur Anwendung kommen, da rferror im ersten Prüfschritt auf >=0 (triff also auch für den Wert 1 zu) geprft wird.
Im zweiten Beispiel wird im ersten Prüfschritt auf >=1 geprüft. Damit wird bei 1 "Fehler" ausgegeben. Bei 0 greift der erste Prüfschritt also nicht und somit geht es weiter zum zweiten Prüfschritt.

Melde dich bitte gern noch mal, wenn die Logik bei dir nicht greift, falls doch noch irgendwo der Fehlerteufel im Detail steckt, behebe ich den natürlich    

[Benni]

Korrektur: das geht schon 

Solange dein set-Befehl nicht an eine Bedingung gebunden ist, die mittels <reading:wert> geprüft werden soll, kannst du das wie folgt machen.

Das ist ja schon mal nicht ganz schlecht. Für meinen konkreten Fall würde das gehen, da kann ich auch mit einem toggle schalten.

Genügt mir fürs erste!

Mal sehen, wann ich was mit Abhängikeit brauche

Danke dir!

gb#

PS: Im Konkreten Fall handelte es sich um meinen Regensensor. Kann jetzt die Heizung des Sensors dank des, per connected verbundenen heating-Kanals schalten. Sehr nice!

[Jamo]

Hallo Jens,
wäre es möglich, bei den Panels auf der rechten Seite zusätzlich zu 'click' und 'link', noch das 'rightMenu' zur Verfügung zu stellen?
Dann hätte man links immer noch den Status Kreis, aber z.B. rechts die Möglichkeit,
- beim Rollo dann feste Längen wie 0%/25%/50%/75%/100% über Menü einzustellen.
- bei Lampen, über rechts entweder verschiedene Scenen, oder fest eingestellte Helligkeitsstufen wie z.B. 0%/20%/40%/60%/80%100%, einzustellen
- bei Thermostaten rechts z.B. die Temperatur in festen Schritten über das Menü einzustellen.

Links im Status Kreis koennte man dann entsprechend den Kreisumfang entsprechend des % Wertes farbig auffüllen.
Oder bei Lightscenen den StatusKreis entsprechend der Farbe der Scene ändern.

Das fände ich super, und ändert hoffentlich auch nichts an der intuitiven Panel Struktur. Danke und Grüsse!

[jemu75]

Hallo Jens,
wäre es möglich, bei den Panels auf der rechten Seite zusätzlich zu 'click' und 'link', noch das 'rightMenu' zur Verfügung zu stellen?
Dann hätte man links immer noch den Status Kreis, aber z.B. rechts die Möglichkeit,
- beim Rollo dann feste Längen wie 0%/25%/50%/75%/100% über Menü einzustellen.
- bei Lampen, über rechts entweder verschiedene Scenen, oder fest eingestellte Helligkeitsstufen wie z.B. 0%/20%/40%/60%/80%100%, einzustellen
- bei Thermostaten rechts z.B. die Temperatur in festen Schritten über das Menü einzustellen.

Links im Status Kreis koennte man dann entsprechend den Kreisumfang entsprechend des % Wertes farbig auffüllen.
Oder bei Lightscenen den StatusKreis entsprechend der Farbe der Scene ändern.

Das fände ich super, und ändert hoffentlich auch nichts an der intuitiven Panel Struktur. Danke und Grüsse!

Das lässt sich grundsätzlich einbauen und gab letztens hier schon mal den gleichen Vorschlag. (und glaube von tomspatz) Ich würde davon abraten, zu viel Funktionalität in die Panels zu packen. Aus meiner Sicht gibt es ja genau für die "komplexere" Steuerung von Devices das Standard-Template. Hier kann man sich mit beliebig vielen Ebenen / Tasten und Menü's "austoben"
Aber das ist nur meine persönliche Meinung.

Ich werde die "Menü-Funktion" aus dem Standard-Template mit in die Panels rüber nehmen. Und dann kann jeder selbst entscheiden ob er das Feature verwendet 

[Jamo]

Ich werde die "Menü-Funktion" aus dem Standard-Template mit in die Panels rüber nehmen. Und dann kann jeder selbst entscheiden ob er das Feature verwendet 

Danke!

[Wzut]

Melde dich bitte gern noch mal, wenn die Logik bei dir nicht greift

Ahh, ja wenn sie kennt kann man sie auch beachten ..... Anyway , dann wäre nur noch meine zweite Frage aus #675 offen.
Bzw. ich selbst nutze FHEMApp nicht, wollte aber als Autor der MAX! Module dafür sorgen das meine "Kunden" passende Templates für ihre Geräte haben. Wie geht das nun weiter, übernimmst du neue Templates in deine git Version oder soll ich sie im MAX Unterforum in irgend eine Ecke legen wo sie vermutlich wieder keiner findet ?
Oder lass dir doch von Rudi einen SVN Zugang geben, dann wäre alles via normalen Update verfügbar ohne dieses git Geschüttel.

[hydrotec]

Kann man so ein, per connected eingebundenes Device auch schalten?

Hallo Benni,

schau mal hier unter Punkt 2.) nach.
Dort schalte ich ein eingebundenes Device. Im Prinzip einfach nur set <devicename> zusätzlich mit angeben.
Wobei es fraglich ist, ob in dem Fall das Device connected sein muss. 

Gruß, Karsten