Hauptmenü

FHEM App - Manage your Home

Begonnen von Gisbert, 12 März 2021, 15:05:20

Vorheriges Thema - Nächstes Thema

binford6000

Zitat von: jemu75 am 09 April 2021, 23:37:38
BITTE MAL UM EUER FEEDBACK

Sehr gerne Jens  :)
Bei mir läuft fhemApp produktiv, und zwar auf

  • je zwei iPhones und iPads
  • Einem Chuwi 8 Zoll billig-Tablet mit Android 5

Zur Performance:


  • Die Performance ist OK. Bei iOS muss man halt die App schließen um den Cache zu leeren.
    Ist aber nur bei einer neuen Version nötig - also ziemlich oft   ;);D
    Bei iOS habe ich auch eine oder zwei "Gedächtnis-Sekunden" bis die Seite wieder geladen ist.
    Das ist aber nicht weiter störend.
  • Beim Androiden mache ich das mit fully beim Start (Bewegungsmelder -> Tablet an -> fully lädt die
    Seite neu. Hier auch keine besonderen Performancer-Probleme - trotz alter Hardware/OS

Zu den Charts kann ich nix sagen - ich plotte nur die CPU um das auch zu testen.

VG Sebastian

binford6000

Zitat von: jemu75 am 09 April 2021, 23:16:32
So geht's natürlich auch, wenn "STOPPED" bzw. "PLAYING" im Reading infoSummarize2 steht. :)
Mal noch was anderes (auch wenn es nicht ganz hierher gehört) Mein Reading "currentSenderInfo" in den Sonos-Devices zeigt seit ein paar Tagen nichts mehr an. Hast du da noch was drin stehen?

Zu dem Thema habe ich mir auch bereits Gedanken gemacht.
Und zwar hatte ich versucht, für sonos2mqtt dein SONOS-Template anzupassen. Vielleicht macht es aber mehr Sinn, etwas generischer an die Sache ranzugehen?


  • Es gibt ja nicht nur SONOS, sondern auch KODI, ENIGMA2, SIRD usw.
    Da gibt es auch überall play/pause/volume usw.
    Gut, hier und da auch ein paar Sonderlocken wie groupVolume, Sender, Favoriten usw.
  • Hier wären dann nur noch die Readings und die wichtigsten set-Befehle je nach verwendetem Modul anzupassen:

    • play, pause/stop, next/previous,...
    • volumeUp, volumeDown, volume, groupVolume,...
    • Favoriten, Radios, Kanäle, etc.
    • Readings: transportState, volume, currentMedia, etc.
Just my 2 ct...  ;)
VG Sebastian

marvin78


marboj

Zitat von: jemu75 am 09 April 2021, 11:53:42
Ja, es gibt aus meiner Sicht mehrere Ansätze
1) du kannst alle Stati deiner Kontakte in die Definition packen. Hierbei beachten, dass die Definitionen von links nach rechts durchgeprüft werden und die Prüfung abgeschlossen wird, sobald eine Bedingung zutrifft
2) du kannst schauen, ob alle Kontakte bei einem bestimmten Zustand den gleichen Wert haben. z.B. "open" und dann für alle anderen Fälle einfach "geschlossen" ausgeben. Das würde z. B. wie folgt aussehen ["state:open:offen", "state::geschlossen"]

Ach und Variante 3 wäre die Verwendung von regex. Hier kannst du tatsächlich mehrere Zustände mit der pipe | prüfen. Hierzu bitte mal regex ansehen. :)

Ergänzung: ich habe mal mit Regexp probiert. Du könntest die Definition wie folgt schreiben:

["state:unknown|close:geschlossen:0:success", "state:open:geöffnet:100:success", "state::teilweise geschlossen:50:success"]

Wobei ich hier noch die Frage hätte, welche Zustände es noch gibt, bei denen "teilweise geschlossen" ausgegeben wird?

Also irgendwie klappt das bei mir nicht oder ich verstehe die Statuszeile falsch: Du hast geschrieben, dass die Stati von links nach rechts abgeprüft werden. Das wird aber doch für jedes Device gemacht, oder?

Habe das Panel so konfiguriert:

{ "panel": { "status": ["state:unknown|close:geschlossen:0:success", "state:open:geöffnet:100:success", "state::teilweise geschlossen:50:success"], "btn": "mdi-chevron-right", "link": "/devices/group=Türen und Fenster" } }

Die Stati der Kontakte kann man im Screenshot erkennen. Nach meinem Verständnis müsste doch jetzt geschlossen angezeigt werden. Es wird aber teilweise geschlossen angezeigt.

Wo ist mein Denkfehler?

Kann es daran liegen, dass die Geräte das Reading state nicht haben sondern nur STATE? Wenn ich STATE anstelle state in die Definition einstelle, verschwindet der Statuseintrag komplett vom Panel...

VG
Marco
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

jemu75

Zitat von: marboj am 10 April 2021, 14:46:47
Also irgendwie klappt das bei mir nicht oder ich verstehe die Statuszeile falsch: Du hast geschrieben, dass die Stati von links nach rechts abgeprüft werden. Das wird aber doch für jedes Device gemacht, oder?

Habe das Panel so konfiguriert:

{ "panel": { "status": ["state:unknown|close:geschlossen:0:success", "state:open:geöffnet:100:success", "state::teilweise geschlossen:50:success"], "btn": "mdi-chevron-right", "link": "/devices/group=Türen und Fenster" } }

Die Stati der Kontakte kann man im Screenshot erkennen. Nach meinem Verständnis müsste doch jetzt geschlossen angezeigt werden. Es wird aber teilweise geschlossen angezeigt.

Wo ist mein Denkfehler?

Kann es daran liegen, dass die Geräte das Reading state nicht haben sondern nur STATE? Wenn ich STATE anstelle state in die Definition einstelle, verschwindet der Statuseintrag komplett vom Panel...

VG
Marco

zu STATE: STATE muss in der Definition anders abgefragt werden, da STATE in Internals liegt und state in den Readings. Um STATE zu prüfen müsstest du Internals.STATE in die Definition schreiben. Aber ich denke, mit STATE kommst du hier nicht weiter.

Dein Screenshot zeigt doch die Stati von verschiedenen Devices. Ich vermute mal, dass das ein "sturcture" ist, von dem der Screenshot stammt - oder?
Wenn ja, welchen Zustand hat das Reading "state" von dem "structure" Device?

marboj

in der Tat ein Structure, wie in der Readme beschrieben. Das hat den Status undefined...
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II

Wzut

Ich habe mich heute mal mit dem Template thermostat befasst und hier meine Version angepasst für MAX! HTs und WTs
{
  "name": "thermostat_max",
  "author": "Wzut",
  "date": "2021-04-10",
  "status": {
    "bar": ["valveposition::%n:success"],
    "error": []
  },
  "main": [
    {
      "leftBtn": "mdi-minus",
      "leftClick": ["desiredTemperature:4.5:desiredTemperature %i-0.5","desiredTemperature::"],
      "leftLong": ["ecoTemperature::desiredTemperature %s"],
      "text": ["desiredTemperature::%s"],
      "rightBtn": "mdi-plus",
      "rightClick": ["desiredTemperature:30.5:","desiredTemperature::desiredTemperature %i0.5"],
      "rightLong": ["comfortTemperature::desiredTemperature %s"]
    }
  ],
  "info": {
    "left1": ["mode:manual::mdi-hand-right","mode:auto::mdi-caps-lock"],
    "left2": ["panel:unlocked::mdi-lock-open-variant-outline","panel:locked::mdi-lock"],
    "mid1": ["temperature::%s°C:mdi-thermometer"],
    "mid2": ["valveposition::%n%:mdi-valve"],
    "right1": ["battery:ok::mdi-battery-90","battery:::mdi-battery-10"],
    "right2": ["rferror:0::mdi-wifi","rferror:::mdi-wifi-off"]
  }
}
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jemu75

Zitat von: marboj am 10 April 2021, 15:26:33
in der Tat ein Structure, wie in der Readme beschrieben. Das hat den Status undefined...

Ja, und wenn du das Template in dem structure Device definiert hast, dann schaut das dort in das Reading state. Das hat den Wert undefined und damit greift der letzte Block in deiner Definition. Ich arbeite auch mit structure Devices und löse das für Kontakte wie folgt. ["state:open:alle offen", "state:closed:alle geschlossen", "state::teilweise offen"]
Diese Definition funktioniert. Jedoch hängt der Wert von state in deinem structure Device auch von den Attributen clientstate_behavior und clientstate_priority ab. Aber falls du diese beiden Attribute nicht gesetzt hast, sollte es wie beschrieben funktionieren.  :)

tomspatz

Zitat von: tomspatz am 07 April 2021, 19:57:09
@jemu75
bei der slider "Geschichte" die du mir verkauft hast  ;)
"slider": ["state::dim %v:%n:0:99"]

gibt es oder sollte es irgendwo eine Anzeige auf oder in dem Slider selbst über den eingestellten Wert?

klopf klopf Jens

jemu75

Zitat von: tomspatz am 10 April 2021, 15:58:14
klopf klopf Jens

Brauchst du eine Anzeige beim Bewegen des Sliders oder geht es dir generell um den eingestellten Wert?

tomspatz

tja wenn ich das wüsste.
ich probiere mich an einem template fürs Thermostat. Da ich verschiedene im Einsatz habe, ist das so das es im Frontend also in dem das die Frau auch bedienen kann, ein drop down list.
Für verschiedene Aktoren dahinte immer verschiedene Logik abei im FE immer das selbe.
Das wäre mir schon fast am liebsten, würde mir aber auch eine Anzeige beim Bewegen des Sliders anschauen. Zumal ich den Sliderwert ja begrenzen kann. Dieser müsste dann aber auch "halbe" Grade können.
Oder halt eich schickes so halbkreis förmiges "ding" welches mit dem dicken finger zu stellen wäre.

Ich möchte dir auch nicht zu viel abverlangen, die neuentwicklung wolltest du ja erstmal drosseln.

Benni

Hallo Jens,

könntest du diese Connected.xxx - Geschichte, die ich in manchen Templates sehe, mal etwas erläutern?


templ_door.json:      "rightClick": ["Connected.button.Internals.NAME::set %s on-for-timer 0.4"]
templ_switch.json:    "error": ["Connected.receiver.Readings.Activity.Value:^(?!alive):100:error:keine Verbindung"]
templ_switch.json:    "right2": ["Connected.receiver.Readings.Activity.Value:alive::mdi-wifi","Connected.receiver.Readings.Activity.Value:::mdi-wifi-off"]
templ_thermostat.json:    "bar": ["Connected.valve.Readings.pct.Value::%n:success"],
templ_thermostat.json:    "error": ["Connected.receiver.Readings.Activity.Value:^(?!alive):100:error:keine Verbindung"]
templ_thermostat.json:    "right1": ["Connected.receiver.Readings.battery.Value:ok::mdi-battery","Connected.receiver.Readings.battery.Value:::mdi-battery-10"],
templ_thermostat.json:    "right2": ["Connected.receiver.Readings.Activity.Value:alive::mdi-wifi","Connected.receiver.Readings.Activity.Value:::mdi-wifi-off"]


Wo gibt's die? Welche gibts da? Wie kann ich das verwenden?

Danke dir schon mal!

gb#

Wzut

@Benni, ich habs so verstanden :
Connected.receiver.Readings.Activity.Value:alive: so Monster brauchst du nur wenn das Reading/Internal/Attribut gar nicht direkt in dem Device selbst liegt sondern wie bei HM üblich ausgelagert in ein Sub Device (channel)
 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

jemu75

Zitat von: Benni am 10 April 2021, 17:58:14
Hallo Jens,

könntest du diese Connected.xxx - Geschichte, die ich in manchen Templates sehe, mal etwas erläutern?


templ_door.json:      "rightClick": ["Connected.button.Internals.NAME::set %s on-for-timer 0.4"]
templ_switch.json:    "error": ["Connected.receiver.Readings.Activity.Value:^(?!alive):100:error:keine Verbindung"]
templ_switch.json:    "right2": ["Connected.receiver.Readings.Activity.Value:alive::mdi-wifi","Connected.receiver.Readings.Activity.Value:::mdi-wifi-off"]
templ_thermostat.json:    "bar": ["Connected.valve.Readings.pct.Value::%n:success"],
templ_thermostat.json:    "error": ["Connected.receiver.Readings.Activity.Value:^(?!alive):100:error:keine Verbindung"]
templ_thermostat.json:    "right1": ["Connected.receiver.Readings.battery.Value:ok::mdi-battery","Connected.receiver.Readings.battery.Value:::mdi-battery-10"],
templ_thermostat.json:    "right2": ["Connected.receiver.Readings.Activity.Value:alive::mdi-wifi","Connected.receiver.Readings.Activity.Value:::mdi-wifi-off"]


Wo gibt's die? Welche gibts da? Wie kann ich das verwenden?

Danke dir schon mal!

gb#

Gern,

im Normalfall verbindest du ein Template immer mit genau einem Device. Somit kannst du erstmal alle Readings/Internals/Attribute von diesem "abgreifen" und im Standard Template verwenden. Wenn du jedoch komplexere Templates erstellen möchtest, die Daten aus unterschiedlichen Devices darstellen sollen, dann kommt connected zum Einsatz. Das bietet sich z.B. bei Thermostaten an, wenn ich im Template zusätzlich sehen möchte, was das zugehörige Heizungsventil macht. Oder wenn, wie bei Homematic-Thermostaten, mehrere Kanäle vorhanden sind.

Mit dem Parameter connected definierst du in appOptions also die Devices, die du noch im Template benötigst. die Angabe erfolgt immer mit "<name>": "<device>". name ist ein von dir gewählter Name, über den du später in der Templatedefinition auf dieses "Kind-Device" zugreifen kannst. Wie du das genau machst, erkläre ich gleich. der "connected-Teil" in appOptions könnte damit wie folgt aussehen:
"connected": { "ventil": "fhem.heizung.ventil.wohnzimmer", "empfängerkanal": "fhem.thermostate.wohnzimmer.empfänger" } 

Wenn du jetzt mehrere Devices in einem Template hast, würden ja "Dopplungen" von Readings/Internals/Attributen entstehen. Damit du nun bei der Zuweisung auf das richtige Reading zugreifst, muss deine Wertzuweisung das Reading genauer spezifiziert werden, indem du den kompletten "JSon-Objectpfad" angibst. Im o.g. Beispiel wäre das dann z.B.
["Connected.ventil.Readings.state.Value"]
Wichtig: in der appOptions-Definition wird der Parameter "connected" klein geschrieben. Im "JSon-Object" musst du "Connected" schreiben.

Ich denke deutlich wird das Prinzip auch noch mal wenn du den DebugModus aktivierst und dann mal auf {...} oben rechts im Standard-Template klickst. Dann wird das komplette JSon-Obejct mit allen verfügbaren Elementen angezeigt.

Soweit ein kurzer Crashkurs zum Thema "connected"  :)

Wzut

@jemu75 , bei der Gelegenheit bin ich über ein kleines Parser Problem gestolpert.
Bei MAX! gibt es zwei Readings, (rferror und onoff)  die beide den Wert 0 oder 1 haben können.
Eine simple Zuweisung im Template ala :
"right2": ["rferror:1::mdi-wifi-off","rferror:::mdi-wifi"]

greift nicht egal welchen Wert rferror (0/1) annimmt. Eine Änderung auf
"right2": ["Readings.rferror.Value:1::mdi-wifi-off","Readings.rferror.Value:::mdi-wifi"]
bringt allerdings den gewünschten Effekt, nur finde ich es nicht logisch (Beim onoff Readings ist es das gleiche Spiel)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher