Hauptmenü

FHEMApp4 - Beta Version

Begonnen von jemu75, 25 Februar 2024, 19:19:13

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Benni am 08 April 2024, 17:16:10grep findet das in folgenden Modulen:

10_RHASSPY.pm
Eventuell lohnt sich für eine generische Umsetzung in Richtung Standardtemplates mal ein Blick in den Code, v.a. in _analyze_genDevType(). Das macht genau das:
Zitat von: jemu75 am 07 April 2024, 15:22:17Habt ihr evtl. Ideen oder Ansätze, wie man in FHEM Devices rausbekommt, um welche Art von Device (z.B. Tür/Fensterkontakt, Dimmer, Schalter, Jalousie, usw.) es sich handelt? Sinnvoller Weise auch herstellerübergreifend.
Das erkennt z.B. auch, ob hue-Setter für Farbe da sind (dann werden in der Regel die verwendet, wenn man nicht "tweakt") oder "nur" RGB, wie weit der "brightness"-Range ist (0-99, 0-100, 0-254, 0-255, oder allg. x-y) und generiert sich eine Art Abstraktionssschicht für generische Befehle.

Bin noch nicht soweit, mit FHEMApp4 starten zu können, kann mir aber vorstellen, dass sich ggf. noch das eine oder andere neben diesem Codeschnippsel von RHASSPY zu FHEMApp4 übertragen läßt...
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

sd

Zitat von: jemu75 am 04 April 2024, 18:57:48
Zitat von: sd am 04 April 2024, 17:45:52Allerdings funktioniert er nur für ein devicekey, bei mehreren werden alle ausser dem ersten ignoriert.

Hallo Steffen,

vielen Dank für den Hinweis. Kannst du bitte noch etwas genauer beschreiben, wie sich das ignorieren bemerkbar macht.
Werden nur die readings vom ersten Device angezeigt oder stehen die anderen Deviceskeys nicht zur Verfügung?
Beides sollte auf jeden Fall nicht so sein. Also "jammern" erlaubt.  ;)

Beste Grüße
Jens  :)
Hallo Jens,
angezeigt wird nur das erste Gerät. Allerdings bin ich mir nicht sicher, ob der Fehler bei mir liegt. Deshalb muss ich noch mehr testen. Ich melde mich wieder.
Gruß
Steffen

sd

zu den automatischen Zuordnungen:
Ich habe Geräte unterschiedlicher Hersteller mit gleicher/ähnlicher Fubktion. Für eine automatische Zuordnung wirkt die unterschiedliche Bezeichnung der Readings in FHEM erschwerend. Das beginnt schon bei so einfachen Readings wie battery, bei mir taucht da "ok/low", "ok 100%/low 0%", "100/0" mit Abstufung, "100%/0%" mit Abstufung und zu guter Letzt andere Readings-Namen auf.
Es macht aus meiner Sicht zur Zeit keinen Sinn, eine automatische Zuornung vorzugeben. Es sollte ja auch die Anzahl der verwendeten Vorlagen des Einzelnen überschaubar bleiben.
Besser finde ich eine Vorlagensammlung, wo mann sich das Geeignetste aussuchen kann.
Gruß
Steffen

Beta-User

Zitat von: sd am 09 April 2024, 12:08:22Es macht aus meiner Sicht zur Zeit keinen Sinn, eine automatische Zuornung vorzugeben. Es sollte ja auch die Anzahl der verwendeten Vorlagen des Einzelnen überschaubar bleiben.
Verstehe ich nur bedingt. Vorlagen sollten (gute) Beispiele sein, die (überschaubar) einen erheblichen Teil der "typischen" Fälle abdecken. Wenn man automatisiert bestimmen kann, was in etwa paßt, ist das erst mal eine gute Basis, verbessern kann man immer noch, indem man seine eigenen (besseren) Vorgaben macht.

PS: z.B. für "battery" gibt es "eigentlich" eine Vorgabe, was in welchem Reading stehen sollte...
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

#334
Guten Abend an alle Tester,

vielen Dank für eure Rückmeldungen und Vorschläge bzgl. der automatischen Erstellung von Panels und Zuordnung von Templates bei neu erstellten Instanzen. Aktuell bin ich mir nicht sicher, ob der Aufwand gerechtfertigt wäre, wenn man die Hürden sieht, die eine saubere Zuordnung mit sich bringen würde. Wahrscheinlich lass ich dieses "Feature" doch erstmal aus der Version 4 raus.

ich habe eben ein weiteres Release v4.0.35-beta freigegeben. Dieses Release enthält folgende Änderungen:

1. im Optionsmenü kann man jetzt die Funktion "Update" aktivieren. Damit wird im Optionsmenü der Punkt "Aktualisierung" angezeigt, sobald ein Update für FHEMApp verfügbar ist. Die neue Funktion prüft das Reading update_available. Damit sind Updates von FHEMApp noch einfacher und direkt über FHEMApp möglich. Nachdem das Update ausgeführt wurde, wird automatisch auch ein Reload von FHEMApp ausgeführt.

2. der Reiter "Kopfzeile" in den Einstellungen wurde in "Allgemein" umbenannt

3. Der darkMode kann jetzt auch über ein beliebiges Reading gesteuert werden. Die Konfiguration ist in den Einstellungen unter dem Reiter "Allgemein" möglich

4. das Problem mit den Sonderzeichen bei Anzeige der Konfiguration in FHEM wurde behoben. (siehe auch unicode problem) Die Lösung dieses Problems bringt einen kleinen "Wermutstropfen" mit sich. Alle bisher in Konfigurationen befindlichen Sonderzeichen und Umlaute müssen einmalig korrigiert werden. Nachdem ihr die Sonderzeichen und Umlaute geändert habt, sollten diese sowohl in FHEMApp als auch in FHEM korrekt angezeigt werden.

Wichtig: Bevor ihr dieses Release installiert, macht bitte auf jeden Fall eine Kopie eurer FHEMApp-Konfiguration! Für den Fall, dass der Pkt. 4 noch irgendwelche Fehler aufwirft, könnte eure Konfiguration zerstört werden.

In diesem Sinne viel Spaß beim weiteren Testen!  :)

Jens


marboj

#335
ZitatDie Lösung dieses Problems bringt einen kleinen "Wermutstropfen" mit sich. Alle bisher in Konfigurationen befindlichen Sonderzeichen und Umlaute müssen einmalig korrigiert werden. Nachdem ihr die Sonderzeichen und Umlaute geändert habt, sollten diese sowohl in FHEMApp als auch in FHEM korrekt angezeigt werden.

Das heißt, dass ich das Update mache und dann alle Umlaute und Sonderzeichen anpasse, wenn diese nicht korrekt angezeigt werden.

Um sich einen Überblick zu verschaffen, was alles zu ändern ist: Im FHEM in dem myapp-Device get myapp rawconfigausführen. Überall, wo eine scharze Raute angezeigt wird, ist Handlungsbedarf.

Bei 18 Vorlagen und 90 Devices ca. 30 Minuten Aufwand...

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

Beta-User

Zitat von: jemu75 am 10 April 2024, 22:26:39Aktuell bin ich mir nicht sicher, ob der Aufwand gerechtfertigt wäre, wenn man die Hürden sieht, die eine saubere Zuordnung mit sich bringen würde.
Glaube nicht, dass der Aufwand wirklich so groß ist. Falls (!) ich dazu komme, werfe ich mal einen Blick in den Code um zu checken, was da eigentlich wo gebraucht wird und ggf. aus dem RHASSPY-Code entlehnt werden könnte. Der ist ja da und funktional - meicht mich aber sicher nicht die kommenden paar Tage.
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

binford6000

#337
Zitat von: marboj am 11 April 2024, 08:00:23Bei 18 Vorlagen und 90 Devices ca. 30 Minuten Aufwand...

Gruß
Marco

Bei 27 Vorlagen und 122 Panels keine 10 Minuten Aufwand:
  • myapp config in einen Editor laden und nach � suchen
  • � durch ä|ö|ü und € durch € ersetzen lassen
  • myapp config wieder hochladen
  • set myapp rereadCfg

VG Sebastian

sd

Ich musste bei mir lediglich die Vorlagen anpassen.
Ein Fehler bei der Panelvorschau in der Vorlagendefinition hat sich mit der neuen Version aufgelöst.
Gruß
Steffen