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
Zitat von: bertl am 26 April 2026, 18:45:53Wenn das disable-Attribut verändert wird (0 oder 1), dann wird FULLY_SetPolling aufgerufen.
Thx für den Hinweis, sollte wieder funktionieren.
Bei der Gelegenheit ist mir noch eine andere Kleinigkeit über den Weg gelaufen, die vermutlich auch nicht (mehr?) wie erwartet funktioniert hat...
Danke für das Update!
Noch eine Kleinigkeit:
Wenn das disable-Attribut = 1 gesetzt ist, wird bei einer Änderung von 'pollInterval' oder wenn 'pollInterval' gelöscht wird, trotzdem der Polling-Timer gesetzt.
Was prinzipiell kein Problem ist, da das FULLY_UpdateDeviceInfo nicht mehr ausgeführt wird.
Aber der Timer (nextUpdate) wird nicht gelöscht.
Möglicher Lösungsvorschlag (2x - # EINGEFÜGT):
sub FULLY_Attr
{
my ($cmd, $name, $attrname, $attrval) = @_;
my $hash = $defs{$name} // return;
if ($cmd eq 'set') {
if ($attrname eq 'pollInterval') {
if ($attrval >= $FULLY_POLL_RANGE[0] && $attrval <= $FULLY_POLL_RANGE[1]) {
return if IsDisabled($name); # EINGEFÜGT
FULLY_SetPolling ($hash, 1, $attrval);
}
elsif ($attrval == 0) {
FULLY_SetPolling ($hash, 0);
}
else {
return "FULLY: Polling interval must be in range ".$FULLY_POLL_RANGE[0]."-".$FULLY_POLL_RANGE[1];
}
}
elsif ($attrname eq 'requestTimeout') {
return "FULLY: Timeout must be greater than 0" if ($attrval < 1);
}
elsif ($attrname eq 'disable') {
if ($attrval eq '0') {
# Set the polling interval to default or the value specified in pollInterval
FULLY_Log ($hash, 2, "Device activated");
FULLY_SetPolling ($hash, 1);
}
elsif ($attrval eq '1') {
FULLY_SetPolling ($hash, 0);
FULLY_Log ($hash, 2, "Device deactivated");
}
}
elsif ($attrname eq 'STTprocessor') {
return "No Babble or RHASSPY device available with name $attrval!" if $init_done && InternalVal($attrval,'TYPE','none') !~ m{Babble|RHASSPY}xms;
}
}
elsif ($cmd eq 'del') {
if ($attrname eq 'pollInterval') {
# Set the polling interval to default
return if IsDisabled($name); # EINGEFÜGT
FULLY_SetPolling ($hash, 1);
}
elsif ($attrname eq 'disable') {
# Set the polling interval to default or the value specified in pollInterval
FULLY_Log ($hash, 2, "Device activated");
FULLY_SetPolling ($hash, 1);
}
}
return;
}
Gruß, Robert
Noch eine Bitte:
Könntest du bitte den 'slider,10,10,86400' bei pollInterval raus geben, da der max-Wert so hoch ist, sodass der slider nicht wirklich verwendbar ist.
Ich will z.B. 600 einstellen und der slider 'hüpft' auf alle Werte hin und her - ausser dem gewünschten Wert.
Danke, Robert
Zitat von: bertl am 28 April 2026, 08:56:37Möglicher Lösungsvorschlag (2x - # EINGEFÜGT):
Danke für's Auffinden! Dachte mir irgendwie schon, dass das mit der Abfrage an der anderen Stelle "eigentlich sinnvoll" wäre...
Die ganze Konstruktion behagt mir nicht so recht, eigentlich wäre es vermutlich hilfreich, die "start()"-Routine (timer-basiert) aufzurufen und alle relevanten Abfragen darüber (zentral) zu erledigen?
Zitat von: bertl am 28 April 2026, 09:22:25Noch eine Bitte:
Wird etwas dauern, bis ich Zeit finde, mir das insgesamt nochmal in Ruhe anzusehen, eventuell könnte man auch einen logaritmisches widget nehmen?
Falls du Lust hast und halbwegs nachvollziehen, was ich damit meine, kannst du gerne entsprechende patches (kann man einfach per "diff -u <alt> <neu>" (oder andersrum?) erzeugen) beisteuern :) .
Zitat von: Beta-User am 30 April 2026, 09:26:15Die ganze Konstruktion behagt mir nicht so recht, eigentlich wäre es vermutlich hilfreich, die "start()"-Routine (timer-basiert) aufzurufen und alle relevanten Abfragen darüber (zentral) zu erledigen?
Ich bin ganz bei dir, wenn du schreibst, dass dir die ganze Konstruktion nicht recht behagt.
Welche genauen Gedanken du mit
"start()"-Routine (timer-basiert) verfolgst, kann ich leider (noch) nicht nachvollziehen.
Bis du Zeit findest dir das Ganze mal in Ruhe anzusehen, würde ich dich bitten folgende Änderung und Fehlerkorrekturen einfach mal einzuchecken.
--- 89_FULLY.pm 2026-05-04 13:01:57.486744949 +0200
+++ 89_FULLY_new.pm 2026-05-04 13:01:36.710893212 +0200
@@ -66,7 +66,7 @@
$hash->{ShutdownFn} = "FULLY_Shutdown";
$hash->{FW_detailFn} = "FULLY_Detail";
- $hash->{AttrList} = "pingBeforeCmd:0,1,2 pollInterval:slider,10,10,86400 requestTimeout:slider,1,1,20 repeatCommand:0,1,2 " .
+ $hash->{AttrList} = "pingBeforeCmd:0,1,2 pollInterval:selectnumbers,0,300,86400,0,lin requestTimeout:slider,1,1,20 repeatCommand:0,1,2 " .
"disable:0,1 expert:0,1 waitAfterPing:0,1,2 updateAfterCommand:0,1 STTprocessor " .
$readingFnAttributes;
return;
@@ -154,6 +154,7 @@
if ($cmd eq 'set') {
if ($attrname eq 'pollInterval') {
if ($attrval >= $FULLY_POLL_RANGE[0] && $attrval <= $FULLY_POLL_RANGE[1]) {
+ return if IsDisabled($name);
FULLY_SetPolling ($hash, 1, $attrval);
}
elsif ($attrval == 0) {
@@ -186,6 +187,7 @@
elsif ($cmd eq 'del') {
if ($attrname eq 'pollInterval') {
# Set the polling interval to default
+ return if IsDisabled($name);
FULLY_SetPolling ($hash, 1);
}
elsif ($attrname eq 'disable') {Danke, Robert
Zitat von: bertl am 04 Mai 2026, 13:23:05Welche genauen Gedanken du mit "start()"-Routine (timer-basiert) verfolgst, kann ich leider (noch) nicht nachvollziehen.
Vielleicht hilft das angehängte diff iVm. mit der Umstellung auf einen timer-basierten Start statt via NotifyFn() aus https://svn.fhem.de/trac/changeset/30999/trunk/fhem/FHEM/89_FULLY.pm.
Bitte testen, falls ich nichts höre und mir auch selbst nichts weiter auffällt, checke ich das bei Gelegenheit ein, groß zum ausdrücklichen Testen werde ich nicht kommen.
Zitat von: Beta-User am 04 Mai 2026, 20:27:16Vielleicht hilft das angehängte diff iVm. mit der Umstellung auf einen timer-basierten Start statt via NotifyFn() aus https://svn.fhem.de/trac/changeset/30999/trunk/fhem/FHEM/89_FULLY.pm (https://svn.fhem.de/trac/changeset/30999/trunk/fhem/FHEM/89_FULLY.pm).
Danke jetzt habe ich es verstanden.
Was mir aufgefallen ist:
- Der Spezialfall wenn pollInterval = 0 ist, wird falsch behandelt.
- Bei jeder Änderung eines Attributes wird "Opening device ..." gelogged.
- Es gibt kein Logging mehr, wenn das Device disabled/enabled wird.
- Das Internals "nextUpdate" stimmt nicht mehr, sobald das Attribut "disable = 1" gesetzt wird.
Somit ist das Logging von "Polling activated/deactivated" ebenfalls falsch.
Der Rest dürfte funktionieren.
:)
Danke für die Rückmeldungen!
...noch nicht fertig, aber hier mal ein (noch ungetestetes) Zwischenergebnis.
Die Loggerei kam mir etwas exzessiv vor, gibt es Gründe, das beizubehalten, oder kann das (wie in dieser Fassung weiter in diese Richtung gedreht) auch entfallen bzw. der Level angepaßt?
Aus meiner Sicht kann die Loggerei angepasst werden.
Der Spezialfall "temporarily disabled" und "pollIntervall = 0" beim Aufruf von FULLY_Start ergibt mit deiner neuen Version eine Loop.
Dieser Spezialfall muss abgefangen werden.
$interval = $FULLY_POLL_INTERVAL if $interval == 0;
Ansonsten scheint die neue Version aufs erte Hinsehen zu passen.
Eventuell das "FULLY_GetDeviceInfo ($name);" verschieben (wie im diff unten angeführt)!?
Da die Device Infos sonst erst nach Ablauf des "pollInterval" aufgerufen werden (außer beim Start von fhem).
--- 89_FULLY_ori.pm 2026-05-05 15:07:21.314199202 +0200
+++ 89_FULLY.pm 2026-05-05 16:13:50.860276224 +0200
@@ -243,7 +243,6 @@
if ( !defined $hash->{nextUpdate} ) {
$hash->{nextUpdate} = 'off';
FULLY_Log ($hash, 3, "Opening device $hash->{host}");
- FULLY_GetDeviceInfo ($name);
}
my $disableLevel = IsDisabled($name);
@@ -254,10 +253,12 @@
if ( $disableLevel > 1 ) { # temporarily disabled?
$hash->{nextUpdate} = "disabled $disableLevel";
- my $interval //= AttrVal ($name, 'pollInterval', $hash->{fully}{interval} // $FULLY_POLL_INTERVAL);
+ my $interval = AttrVal ($name, 'pollInterval', $hash->{fully}{interval} // $FULLY_POLL_INTERVAL);
+ $interval = $FULLY_POLL_INTERVAL if $interval == 0;
return InternalTimer(gettimeofday()+$interval, \&FULLY_Start, $hash, 0);
}
+ FULLY_GetDeviceInfo ($name);
return FULLY_SetPolling ($hash, 1);
}
:) So macht das Freude - ich muss mich zwar mehr um das Thema kümmern als eigentlich Zeit dafür ist, aber es kommt immerhin was konstruktives raus, DANKE!
Zitat von: bertl am 05 Mai 2026, 16:14:54Eventuell das "FULLY_GetDeviceInfo ($name);" verschieben (wie im diff unten angeführt)!?
Habe mal in der "alten" Fassung mit NotifFn-Start nachgesehen - https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/89_FULLY.pm?rev=30558. Da wurde das (m.E. ungünstig, einer der Gründe für den Wechsel zu timer-basiert...) nur im define aufgerufen oder bei expliziter Anforderung. Von daher gäbe es vergleichend keinen Anlass, das noch zu einem anderen Zeitpunkt als einmalig zum FHEM-Start auszuführen. Übersehe ich bei diesem überschlägigen Vergleich was wichtiges?
Was das mit der loop angeht: Wäre es nicht "richtig", in dem (dankenswerterweise korrekte bemängelten) Fall das aktive Hochsetzen des Intervals durch den User vorauszusetzen und einfach gar keinen Timer mehr zu setzen:
- $interval = $FULLY_POLL_INTERVAL if $interval == 0;
+ return if !$interval;
Ja, so macht es spaß!
Zitat von: Beta-User am 05 Mai 2026, 16:42:22Übersehe ich bei diesem überschlägigen Vergleich was wichtiges?
Nein, da geht es aus meiner Sicht nur um Kosmetik.
Sobald das Polling wieder aktiviert wird, muss zuerst das "pollInterval" verstreichen, dass ein Update passiert.
Anders würde gleich ein Update angestoßen werden.
Bevor wir uns jetzt bezüglich loop und dessen Auswirkung genauer unterhalten, eine grundsätzliche Frage an dich:
Wie kann der Fall, dass der $disableLevel > 1 wird überhaupt eintreten, speziell in diesem Modul?
Zitat von: bertl am 05 Mai 2026, 19:13:15Wie kann der Fall, dass der $disableLevel > 1 wird überhaupt eintreten, speziell in diesem Modul?
Derzeit tritt dieser Fall ohne Manipulation durch den User nicht ein :) . Da es Leute geben soll, die ihr WLAN nachts abschalten, könnte aber über ein Attribut "disabledForIntervals" nachdenken; das hatte ich im Hinterkopf bei der Umstellung auf IsDisabled() ;) .
Zitat von: bertl am 05 Mai 2026, 19:13:15Anders würde gleich ein Update angestoßen werden.
Muss ich mir ansehen, scheint dann eine indirekte Folge zu sein, bei der wir auch den direkten Weg gehen könnten und sollten...?
EDIT: Du meinst wohl, dass man FULLY_UpdateDeviceInfo() aufrufen soll? Das macht m.E. Sinn.
Zitat von: Beta-User am 06 Mai 2026, 07:30:35über ein Attribut "disabledForIntervals" nachdenken
Ja, dann macht "return if !$interval;" Sinn.
Weil bei einer mögliche Implementierung des "disabledForIntervals" der Timer wieder angestoßen werden würde/müsste.
Zitat von: Beta-User am 06 Mai 2026, 07:30:35Du meinst wohl, dass man FULLY_UpdateDeviceInfo() aufrufen soll?
Nein ich meine nicht "FULLY_UpdateDeviceInfo" sondern "FULLY_GetDeviceInfo".
Beide Funktionen machen ja das gleiche, bis auf das "FULLY_SetPolling".
Und das wird ja in "FULLY_Start" gesetzt.
Daher denke ich, dass das Verschieben von "FULLY_GetDeviceInfo" wie im Post https://forum.fhem.de/index.php?msg=1363144 vorgeschlagen, passen sollte.
Da es ja nur um das Update der Readings geht und nicht um das Polling.
EDIT: "FULLY_Start" wird beim Define und wenn sich Attribute ändern aufgerufen - somit sollte das "FULLY_GetDeviceInfo" keine Probleme machen.
Spannende Erkenntnis:
Ich habe FHEM neu gestartet und siehe da, FULLY_Start wurde nicht aufgerufen.
Somit gibt es auch kein Polling und das Modul macht nichts, es steht wie ein Stein.
Nach genauerer Analyse habe ich das Problem gefunden.
Beim Startup wird zuerst "FULLY_Define" aufgerufen und nachdem "init_done" noch 0 ist, der Timer zum Aufruf von "FULLY_Start" gestartet.
Im Anschluss wird automatisch "FULLY_Attr" nacheinander mit den bestehenden Attributen aufgerufen.
Und hier werden alle Timer gelöscht und keiner mehr aufgerufen, nachdem "init_done" immer noch 0 ist.
Folgende Änderung in "FULLY_Attr" löst das Problem:
- RemoveInternalTimer($hash);
- return InternalTimer(gettimeofday()+1, \&FULLY_Start, $hash, 0) if $init_done;
+ if ($init_done) {
+ RemoveInternalTimer($hash);
+ return InternalTimer(gettimeofday()+1, \&FULLY_Start, $hash, 0);
+ }
:o Ups...
Habe beides jetzt geringfügig anders sortiert und stelle mir jetzt die Frage, ob man a) setPolling überhaupt in der Form benötigt, und b) ob es tatsächlich ok ist, bei einem deaktivieren Device diese erste Anfrage zu machen?!?
Nun ja, einen Schritt nach dem anderen.
...wird immer besser :)
ad a) was genau meinst du damit?
ad b) diese erste Abfrage in "FULLY_Start" würde ich nach den disable-Abfragen machen und zusätzlich bei der "$hash->{nextUpdate}" Abfrage auf "disabled" prüfen. Weiters sollte das "FULLY_GetDeviceInfo" innerhalb der Abfrage gestrichen werden.
in etwa so:
@@ -241,12 +241,6 @@
#if (!exists($hash->{fully}{password})) {
#}
- if ( !defined $hash->{nextUpdate} ) {
- $hash->{nextUpdate} = 'off';
- FULLY_Log ($hash, 3, "Opening device $hash->{host}");
- FULLY_GetDeviceInfo ($name); #review needed. Should this really happen when device ist disabled?
- }
-
my $disableLevel = IsDisabled($name);
if ( $disableLevel == 1 ) { # Return without any further action if the module is disabled
$hash->{nextUpdate} = 'disabled';
@@ -260,8 +254,12 @@
return InternalTimer(gettimeofday()+$interval, \&FULLY_Start, $hash, 0);
}
+ if ( !defined $hash->{nextUpdate} or $hash->{nextUpdate} =~ "disabled") {
+ $hash->{nextUpdate} = 'off';
+ FULLY_Log ($hash, 3, "Opening device $hash->{host}");
+ }
+
return FULLY_UpdateDeviceInfo($hash); # internally calls setPolling... review of setPolling wrt. to complete code restructuring?
- #return FULLY_SetPolling($hash, 1);
}
...auf die Schnelle - es lädt, sonst nicht wirklich getestet...
setPolling ist noch drin, wird aber wohl nicht mehr aufgerufen.
Im Prinzip machen wir alle Prüfungen in "Start", von daher war vieles doppelt, oder?
Was mir aufgefallen ist:
1) Der Aufruf von "FULLY_Start" im "FULLY_Set" ist falsch geschrieben - "Fully_Start"
2) In "FULLY_UpdateDeviceInfo" wird der Spezialfall "pollInterval = 0" nicht behandelt.
irgendwie so:
@@ -769,6 +769,10 @@
FULLY_ExecuteNB ($hash, ['deviceInfo'], undef, 1);
RemoveInternalTimer ($hash, 'FULLY_UpdateDeviceInfo');
my $interval = AttrVal ($hash->{NAME}, 'pollInterval', $hash->{fully}{interval} // $FULLY_POLL_INTERVAL);
+ if( $interval == 0 ) {
+ $hash->{nextUpdate} = 'off';
+ return;
+ }
$interval = maxNum($FULLY_POLL_RANGE[0],minNum($interval,$FULLY_POLL_RANGE[1]));
# FULLY_Log ($hash, 2, 'Polling activated') if exists $hash->{nextUpdate} && $hash->{nextUpdate} eq 'off';
$hash->{nextUpdate} = strftime "%d.%m.%Y %H:%M:%S", localtime (time+$interval);
Zitat von: bertl am 07 Mai 2026, 20:49:081) Der Aufruf von "FULLY_Start" im "FULLY_Set" ist falsch geschrieben - "Fully_Start"
Danke für den Hinweis und Sorry für den Typo!
War gestern sehr wenig Zeit, jetzt auch nur ein paar kurze Anmerkungen zu 2):
"Eigentlich" sollten wir in der Funktion (fast*) keine Prüfungen mehr benötigen, dass das minmax-Ding überhaupt noch drin steht, war nur der Sorge geschuldet, wieder eine unbeabsichtigte loop zu bauen. Das kommt dann auch noch raus, wenn wirklich geprüft wurde, ob die Funktion tatsächlich nur aus "start" heraus (erstmalig) aufgerufen werden kann.
Was allerdings fehlt, ist (=>*) IsDisabled()... Wenn nämlich diese reguläre timer-Funktion läuft, kann zwischenzeitlich ja ein temporarily-Zustand eintreten. Da müßte man den nächsten Timer ohne zwischenzeitliche Anfrage setzen, der Einfachheit halber reicht das m.E. ohne weitere Differenzierung.