Hallo zusammen,
da zap bereits vor längerem mitgeteilt hatte, dass er sich künftig nicht mehr um das FULLY-Modul für den fully-Browser kümmern zu können und das Modul ganz gut zu meiner eigenen FHEM-Weiterentwicklungs-roadmap zu passen scheint, werde ich mich künftig - zunächst kommissarisch - um das Modul kümmern.
Falls sich jemand findet, der das ggf. mittelfristig (mit) übernehmen möchte, wäre das klasse, denn allzuviel Zeit kann und will ich dem Thema nicht widmen.
Mit dem nächsten update düfte zunächst einfach eine (funktional) auf den "id"-Standard umgebogene Commandref kommen, so dass man jetzt in der Device-Ansicht jeweils eine kurze Erläuterung zu den set-Kommandos und Attributen angezeigt bekommt und vielleicht ein paar erste Schritte zur Anpassung an PBP-Vorschläge (perlcritic).
Irgendwelche Kenntnisse im Modul-Code dürft ihr (noch) nicht erwarten, ich bin bisher einfach auch User des Browsers gewesen, und habe erst kürzlich das Modul erstmals definiert und eine PLUS-Version erworben, die zwischenzeitlich knapp 11 Euro kostet...
Wer Fragen oder Anregungen hat, möge diese bitte hier platzieren und/oder für "spezielle Themen" auf separate Threads ausweichen. Wer die Pflege stattdessen lieber selbst (statt meiner oder ergänzend) übernehmen möchte, darf sich BITTE (!) melden.
Meine Vorstellung von dem, wie fully+FULLY eingesetzt werden soll, scheint etwas anders zu sein als die der meisten bisherigen User, die damit v.a. eine von FHEM aus steuerbare fullsceen-Browser-Lösung für ein stationäres Tablet verwirklicht haben.
Die "Mission" wäre, via fully und FHEMApp (https://forum.fhem.de/index.php?board=104.0) iVm. etwas "js-Magie" ein (auch) via Spracheingabe steuerbares FHEM-Interface für die diversen Androiden in der Famile zu basteln. Der "Schubs" in diese Richtung kam über die Vorstellung der FHEMVoiceClient.akp (https://forum.fhem.de/index.php?topic=142927.0), gepaart mit der ernüchternden Feststellung, dass es heute noch viel schwieriger ist wie vor einigen Jahren schon, AMAD auf aktueller (Tasker-) Basis (https://forum.fhem.de/index.php?topic=143045.0) ans Laufen zu bekommen. Wenn das mit der Spracheingabe (wieder) über AMAD klappen würde, wäre das schön, aber im Moment scheint mir der Versuch lohnend, das ohne diesen (gefühlt riesigen) overhead hinzubekommen.
Von daher die dringliche Bitte: Falls hier jemand mitliest, der irgendeine Idee hat, wie man ein per touch aktivierbares Mikrofon-Overlay (per javascript) bastelt, das den STT-Teil übernimmt und an FHEM übermittelt (und optimalerweise auch von FHEM aus aktiviert werden kann) - jeder Code-Schnippsel ist willkommen!!!
Meine Erfahrungen mit FULLY fingen jetzt jedenfalls erst mal damit an, dass die IP-Adresse meines Androiden unterschiedlich war, je nach genutzem AP und Frequenz :o . Also schon mal nix mit zuverlässigen reconnects.
Vielleicht hilft da die MQTT-Schnittstelle weiter, wir werden sehen.
Soviel erst mal für's erste,
Beta-User
Hallo Beta-User.
schön zu hören, dass sich da zukünftig jemand darum kümmert!
Ich nutze das Modul bisher aber auch nur für stationäre Tablets. Allerdings habe ich auch bei denen im Router (Fritzbox) eine feste IP-Adresse eingestellt. Das mache ich eigentlich für alle Geräte, die das Netzwerk dauerhaft nutzen, egal ob per Ethernet oder WLAN. Das Problem hätte ich also nicht.
Was ich damit mache, ist hauptsächlich die Sprachausgabe und die Ermittlung des Akku-Standes, damit die Tablets nicht dauerhaft geladen werden.
Viele Grüße
Thomas
Danke für die nette Rückmeldung, und Danke auch an @fruemmel für das Aufspüren und fixen des ersten von mir eingeführten (und bemerkten) bugs ;D .
Morgen sollte das mit diesem Bug schon wieder Geschichte sein, außerdem gibt es - ein RIESIGES DANKE an schwatter und Rudi - neue Funktionalität 8) .
Details dazu sind hier zu finden: https://forum.fhem.de/index.php?msg=1360222
Bin mal gespannt, wie ihr das so findet :) .
Hallo Beta-User,
mir ist noch folgender Fehler aufgefallen:
Wenn das disable-Attribut verändert wird (0 oder 1), dann wird FULLY_SetPolling aufgerufen.
Gleich am Anfang von FULLY_SetPolling fragst du das disable-Attribut ab.
return if !$init_done || AttrVal($hash->{NAME}, 'disable', 0);
Zu diesem Zeitpunkt liefert aber AttrVal(...) noch den alten Wert, da dieser erst am Ende durch die aufrufenden Funktion FULLY_Attr aktualisiert wird.
Somit wird das Polling nach einem Setzen von 'disable = 0' nicht mehr aktiviert.
Bitte beheben.
Danke, Robert