Hauptmenü

rooms (und evtl. groups)

Begonnen von Beta-User, 22 Mai 2024, 18:32:41

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

mache grade auch meine ersten Schritte mit FHEMApp4. Erster Eindruck ist "toll"! Noch cooler wie die alte Fassung.

Jetzt habe ich aber das Problem, dass hier häufig Devices in mehreren Räumen sind, v.a. wegen Sprachsteuerung (RHASSPY), und teils wegen des Überblicks.

 Die "zusätzlichen" Räume brauche ich für FHEMApp aber eigentlich nicht, sondern nur den ersten in der Liste (nennt sich bei RHASSPY "Hauptraum")...
 
Ähnlich könnte es ggf. bei Gruppen sein.

Gibt es eine Option, das irgendwo global einzustellen? (Habe zugegebenermaßen nicht allzu intensiv gesucht, aber nichts gefunden außer "eigentlich wollen wir die globalen Einstellungen möglichst einfach halten"...).

Danke vorab!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jemu75

Hallo Beta-User,

ich vermute, dass Du die Standard-Templates verwendest. Hier wird für die Zuordnung der Panels in das Navigationsmenü auf die beiden FHEM-Attribute "room" und "group" zugegriffen. Generell wird beim Zugriff auf FHEM Readings bzw. Attribute jeweils der gesamte Inhalt verarbeitet. Wenn ich dich richtig verstanden habe, dann enthält dein Attribut "room" mehrere (über Komma getrennte) Räume. Die werden damit alle von FHEMApp verarbeitet.

In der Version 3 hatten wir das Thema auch schon und deshalb haben sich zwei Ansätze herausgebildet. Entweder verwendet man konsequent die Räume und Gruppen aus FHEM oder man definiert die Zuordnung komplett in FHEMApp

In deinem Fall wäre der zweite Ansatz ggf. ratsam. Du könntest bei Verwendung der Standard-Templates die erweiterten Panel-Einstellungen nutzen und hier das Element navigation verwenden, um das jeweilige Panel an der bzw. den gewünschten Punkten im Navigationsmenü zu platzieren.

siehe dazu auch Dokumentation

Lass mich bitte mal wissen, ob Dir der Ansatz weiterhilft.

Beste Grüße
Jens :)

Beta-User

Hallo Jens,
vorab: Die Doku ist vorbildlich!
Von daher hatte ich wohl gesehen, dass es die Option gäbe, das ganze via individueller Einstellung bei jedem "template" vorzunehmen. Unter einem "template" hatte ich zwar bisher immer eher eine "allgemeine Vorlage" verstanden und gehofft, dass es eine einfache und generalisierende Möglichkeit gäbe, bestimmte Dinge, die (vermutlich nicht nur bei mir, s.u.) immer wieder vorkommen, auch allgemein für FHEMApp4 zu deaktivieren...

In Detail sieht das bei mir z.B. so aus:
attr Thermostat_EssZi_Climate room Esszimmer,Steuerung->Heizung
attr OBIS_Stromzaehler group Strom
attr OBIS_Stromzaehler room Startseite,Steuerung->Strom

Alle "technischen" Geräte sind also in der Regel (mindestens einmal) irgendwo in einem Unterraum unter "Steuerung" zu finden, was aber "nur" dazu dient, die recht schnell beim passenden Thema bei der Hand zu haben, aber nicht für eine "Strukturierung für Enduser" gedacht ist. Andere FHEM-User dürften ähnliche Themen haben, wenn sie "room" für die Unterordnung unter eine Sprachsteuerung (afair ticken siri und alexa so) oder für MQTT (mit MQTT_GENERIC_BRIDGE) benutzen.

Also falls da was in diese Richtung ("negative devspec" für rooms, ...) möglich wäre, wäre das m.E. eine Erleichterung, nicht nur für mich.

Danke vorab jedenfalls für's darüber nachdenken!


PS: Das Thema "genericDeviceType" (möglichst mit automatisierter Erkennung) ist mir bei der Gelegenheit auch nochmal über den Weg gelaufen. Es wäre m.E. wirklich eine Einrichtungserleichterung, wenn das ähnlich laufen könnte wie bei RHASSPY - einfach nur in der Config erst mal festlegen, dass das Device in RHASSPY respektive FHEMApp erscheinen soll, und es wird automatisch der richtige genericDeviceType (aka "template") zugewiesen (und z.B. auch der Wertebereich erkannt, den das FHEM-Device kennt für "brightness", ...).
Wem dann das Ergebnis nicht gefällt, kann und muss individuelles Feintuning betreiben, aber nötig ist das m.E. eigentlich bei 80-90% der Devices nicht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jemu75

Hallo Beta-User,

zur Steuerung der Navigationspunkte hätte ich noch folgenden Vorschlag. Ich könnte in den Einstellungen unter dem Tab Navigation eine weitere Option hinzufügen, welche es ermöglicht, bestimmte Navigationspunkte generell auszublenden.
Wie das aussehen könnte, habe ich mal im beigefügten Screenshot angefügt. Im Beispiel gibt es einen Navigationspunkt "groups". Diesen kann man über die Option "versteckt" generell aus der Navigationsleiste ausblenden.

Wenn das für dich passt und auch für andere Benutzer, die z.B. RHASSPY einsetzen hilft, dann würde ich das mit der nächsten Version so umsetzen.

Zum Thema "automatische Templatezuordnung" im Zuge der Ersteinrichtung mache ich mir bei Gelegenheit nochmal Gedanken. Wird aber vermutlich erst, wenn es auf die Wintermonate zugeht. ;-)

Grüße
Jens :)

Benni

Also ich habe das bei mir über ein separates Attribut gelöst.

Das Attribut heißt faRoom (bzw. faGroup) und ist am global device in den userattr definiert. Steht somit bei allen Geräten zur Verfügung

Das wird dann in meinen FHEMApp-Templates verwendet, um die entsprechende Navigationszuweisung zu machen.

Also das ganze unabhängig von room und group.

gb#

sd

Ich habe ebenfalls den Ansatz von Benni genutzt. Eventuell kann man das neue Attribut auch ermitteln über einen geeigneten Ausdruck.
Gruß
Steffen

Himbi777

Ich habe zum größten Teil die Zuordnungen aus den Readings room und group übernommen.
Wenn es dann doch bei dem ein- oder anderen Panel nicht gepasst hat, habe ich dies im entsprechenden Panel unter dem Punkt "navigation" angepasst. Es wird dann dieser Punkt im Panel überschrieben, der Rest wird aus dem Template weiterhin übernommen.

Gruss Gerhard
Raspberry Pi4, OMV, FHEM, FHEM-App // Tasmota-Geräte, Zigbee2Tasmota,

Beta-User

Zitat von: jemu75 am 24 Mai 2024, 19:52:47in den Einstellungen unter dem Tab Navigation eine weitere Option hinzufügen, welche es ermöglicht, bestimmte Navigationspunkte generell auszublenden.
Sorry dass es etwas gedauert hat, bis ich mich wieder damit beschäftigen konnte.

Das generelle Ausblenden finde ich nicht unbedingt zielführend, die Einteilung in "rooms" und "goups" ist ja sinnvoll, es ist in der Tat eigentlich wirklich nur ein bestimmer Zweig, den ich nicht benötige - und wie gesagt, eigentlich war ich davon ausgegangen, dass das noch ein paar mehr Leute ähnlich betrifft. Nach den bisherigen Rückmeldungen scheint das eher nicht so zu sein...

Was "groups" angeht, habe ich meine Konfiguration zwischenzeitlich nochmal durchgesehen, da gibt es das vermutete "Problem" gar nicht, es betrifft nur "rooms".

Zitat von: Benni am 26 Mai 2024, 16:44:56Also ich habe das bei mir über ein separates Attribut gelöst.

Das Attribut heißt faRoom (bzw. faGroup) und ist am global device in den userattr definiert. Steht somit bei allen Geräten zur Verfügung

Das wird dann in meinen FHEMApp-Templates verwendet, um die entsprechende Navigationszuweisung zu machen.

Also das ganze unabhängig von room und group.

gb#
Zuerst hat sich da bei mir Widerstand geregt, ich will eigentlich nicht alle möglichen Infos doppelt pflegen, nur weil es in einzelnen Fällen sinnvoll ist.

ABER: Da FHEMApp ja mehrsprachig angelegt ist (und man jedenfalls (auch) mehrere Instanzen) haben kann, gefällt mir das jetzt eigentlich ganz gut! Was mir weiterhin sehr widerstrebt ist der Gedanke, dann alle templates doppeln zu müssen. Ist zwar auch "nur" Einmalaufwand, aber anscheinend betreiben den doch mehrere...

Dazu ein Vorschlag an euch beide, @jemu75 und @benni: Dieses Attribut (bzw. diese Attribute) sollte(n) - falls vorhanden - vorrangig zu dem "normalen" room- bzw. group Attribut ausgelesen werden!

Wenn man das einheitlich so handhabt (z.B. Attributname = FHEMApp-Instandname+"_"room etc.), könnte man nämlich via FHEMApp-Instanz auch gleich die globalen Attribute erlauben und eine passende Hilfe dazu anzeigen (wie das u.a. RHASSPY oder MQTT_GENERIC_BRIDGE heute schon machen), und die individualisierende (und sprachenunabhängige) Konfiguration wäre sehr easy.
Hoffe, das ist verständlich?

Was anderes: Meine Verbindung (von remote via Mobilfunk) läd ständig die Einrichtungsseite neu - das ist so nicht tauglich. Änderungsvorschläge zu den FHEMWEB-Einstellungen oä?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Zitat von: Beta-User am 27 Mai 2024, 18:07:52Zuerst hat sich da bei mir Widerstand geregt, ich will eigentlich nicht alle möglichen Infos doppelt pflegen, nur weil es in einzelnen Fällen sinnvoll ist.

ABER: Da FHEMApp ja mehrsprachig angelegt ist (und man jedenfalls (auch) mehrere Instanzen) haben kann, gefällt mir das jetzt eigentlich ganz gut! Was mir weiterhin sehr widerstrebt ist der Gedanke, dann alle templates doppeln zu müssen. Ist zwar auch "nur" Einmalaufwand, aber anscheinend betreiben den doch mehrere...

Dazu ein Vorschlag an euch beide, @jemu75 und @benni: Dieses Attribut (bzw. diese Attribute) sollte(n) - falls vorhanden - vorrangig zu dem "normalen" room- bzw. group Attribut ausgelesen werden!

Das kannst du doch selbst machen. Die Angabe unter "navigation" im Template ist ja ebenfalls eine bedingte Angabe. Dort kannst du ja auch sowas angeben wie:

door-a-faRoom:.+:rooms->%s

Da braucht man auch keine Templates zu doppeln, denn das kann ich ja in jedes Template einbauen. Wirkt ja erst, wenn im Attribut "faRoom" des device (hier door) was eingetragen ist.

Und ja, durch die Verwendung eigener Attribute, kann man das natürlich prima auch in Verbindung mit der Mehrsprachigkeit von FHEMApp nutzen.

Allerdings erfolgt die Auswertung der Bedingungen nicht nach dem Prinzip "Der erste Ausdruck der passt wird genommen" sondern es werden alle Definitions unter navigation in einem Panel ausgewertet und alle, die passen werden genommen.

gb#

jemu75

Gut, vielen Dank für eure Rückmeldung. Dann würde ich meinen Vorschlag mit dem "versteckt" Parameter nicht weiter verfolgen.  :)

Grüße
Jens

Beta-User

Vielen Dank @Benni für die Erläuterung, dann werde ich das mal so angehen.
"Doppelt" ist dann aber trotzdem noch der Umstand, dass man das in allen templates jeweils einpflegen muss - meine Idee war, das "global" (als default-Verhalten) direkt zu vercoden.
Vergleich zu RHASSPY: Wenn man 2 Instanzen davon hat (z.B. für Deutsch + Spanisch, nennen wir sie rhasspy_de und rhasspy_es), dann hätte man für räumliche Zuordnungen zwei zusätzliche Attribute für ein Device, das von beiden Instanzen steuerbar ist: rhasspy_deRoom und rhasspy_esRoom.

RHASSPY kennt seine Instanz-Namen und geht nach der Regel vor, dass <Instanzname>Room "ihm" gehört und das intern _für diese Instanz_ dann statt des allg. "room"-Attributs genutzt werden soll... (Und die Attribut-Hilfe zeigt auch an, wie es zu machen ist). (Das mit der Instanznamens-Attributhilfe ist z.B. auch so bei MQTT_GENERIC_BRIDGE, wem das RHASSPY-Modul zu "exotisch" ist).
Klar, es ist alles kein riesen Aufwand, das "händisch" zu doppeln und die templates anzufassen, aber wie gesagt: Das ist eigentlich bei allen Usern gleich und daher m.E. "vermeidbar"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files