wunsch nach reading, das die warnungen der fritzbox zeigt (rote info led)

Begonnen von frank, 04 Februar 2025, 11:49:04

Vorheriges Thema - Nächstes Thema

frank

hallo jörg,

die neue automatische erkennung des events "NO_CONNECTION" scheint bei mir gut zu funktionieren, danke.


aktuelle todo list aus meiner sicht:

1. "attr enableBoxReadings box_notify" verschwindet weiterhin bei fhem restart.

2. in zeile 4733 fehlt das "<html>" tag:
#           $content = "- solved - <a href='/fhem?cmd=deletereading%20-q%20" . $name . "%20" . $rName . $uid . ".*" . $FW_CSRF . "' target='_self'>&lt;quittieren&gt;</a></html>";
           $content = "<html>- solved - <a href='/fhem?cmd=deletereading%20-q%20" . $name . "%20" . $rName . $uid . ".*" . $FW_CSRF . "' target='_self'>&lt;quittieren&gt;</a></html>"

3. die cmd-beschreibung zu "ledSetting notifyoff" fehlt noch.

4. die ausführung des cmd "ledSetting notifyoff" wirft grundsätzlich einen fehler im log, obwohl der cmd offensichtlich immer bestens funktioniert (rote led wird ausgeschaltet):
2025.02.17 08:32:03.189 2: [fritzbox | 7490 | 113.07.60 | Set.2181] - SIGNIFICANT:ledsetting notifyoff:8_1 - not appliedliegt das eventuell daran, dass das zyklische pollen der fritzbox daten im hintergrund läuft.
das dauert bei mir in der regel gute 30s (gelegentlich bis zu 40s) mit einem zyklus von 60s.
oder wird nur eine falsche info ausgegeben?

5. es gibt scheinbar auch ein "STATE"-event zum cmd ledSetting?
2025-02-16_12:02:18 fritzbox ledSetting notifyoff:8_1leider kommt das nur selten, eher sporadisch vor. könnte am attr event-on-change=.* liegen.
da es aber in keinem reading auftaucht, kann ich nicht über event-on-update "nachhelfen".

oder sollte das nicht eher im reading retStat_SetGet_nonBlocking auftauchen?
eine regelmässige info im log wäre, gerade zum testen, sehr hilfreich.



Zitat von: JoWiemann am 14 Februar 2025, 08:46:42Und, eine Bitte. Würdest Du bitte einmal in den Entwicklertools nachsehen, welche Aufrufe, neben home/home.js, noch gemacht werden. Danke Dir.
home.js aufrufe habe ich gar nicht gesehen.
da es keine requests gibt, wenn ich in der warnung auf der overview seite auf details klicke, habe ich in allen js-dateien nach den "detail texten" gesucht und bin nur in home.js fündig geworden.

explizite aufrufe, die zu den zyklischen requests bei aktivem alarm angezeigt werden:
sendXhr
http://192.168.1.1/js/http.js:24:41
start
http://192.168.1.1/js/http.js:30:5
getData
http://192.168.1.1/js/refreshTimer.js:28:394
restartRefreshTimer/refreshTimers[timerId].obj<
http://192.168.1.1/js/refreshTimer.js:10:308
(Async: setTimeout handler) restartRefreshTimer
http://192.168.1.1/js/refreshTimer.js:10:279
setRefreshTimers/<
http://192.168.1.1/js/refreshTimer.js:15:49
setRefreshTimers
http://192.168.1.1/js/refreshTimer.js:14:24
lib.init
http://192.168.1.1/home/home.js:93:113
loadJsPage/<
http://192.168.1.1/js/main.js:178:303
(Async: promise callback) loadJsPage
http://192.168.1.1/js/main.js:178:144
loadNewPage
http://192.168.1.1/js/main.js:179:275
lib.changePage
http://192.168.1.1/js/main.js:202:218
lib.init
http://192.168.1.1/js/main.js:218:200
<anonym>
http://192.168.1.1/index.lua:117:6


ich habe meine home.js mal angehängt.
oder habe ich dich falsch verstanden?


gruss frank




FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

JoWiemann

Hallo Frank,

anbei die nächste Version zum Testen.

  • war ein grundsätzlicher Fehler mit dem Attribut, der bisher nicht aufgefallen ist. Sollte jetzt korrigiert sein
  • korrigiert
  • kommt noch, wenn alles funktioniert. set <FB-Device> ledSetting <notifyoff:><ID><br>
    Ich habe zusätzlich ein Log eingebaut, dass die Rückgabe wegschreibt. Hier würde mich Deine Rückgabe interessieren.
  • dafür brauche ich die Rückgabe. Ich war vom üblichen apply: ok ausgegangen.
  • dass mit dem "STATE"-event muss ich mir bei Gelegenheit ansehen. Das set war echt auf die Schnelle für den Link im Reading.
  • mit der home.js komme ich so nicht weiter. Ein Testaufbau mit einer FritzOS Version < 8.00 und einer alten FB dauert noch. Ich weiß noch nicht, wann ich für den Aufwand Zeit finde.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

juemuc

Hallo Jörg,

das Attribut "enableBoxReadings box_notify" wird nun bei einem Neustart nicht mehr gelöscht.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

frank

moin jörg,

attr enableBoxReadings überlebt jetzt auch bei mir.


Zitat von: JoWiemann am 17 Februar 2025, 15:28:124. dafür brauche ich die Rückgabe. Ich war vom üblichen apply: ok ausgegangen.
da kommt die normale json antwort der overview seite wie bei meshrole.
der cmd war also erfolgreich, wenn der key data/notify entsprechend bereinigt wurde.
als bsp der anfang; sollte ja genügen:
$VAR1 = {
          'time' => [],
          'sid' => '3d5d73884e213dbc',
          'sidNew' => 0,
          'timeTillLogout' => '1200',
          'pid' => 'overview',
          'data' => {
                      'fritzos' => {
                                     'isLabor' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
                                     'energy' => '38',

auch beim senden von ledsetting während kein alarm aktiv ist, kommt der overview json.

sinnvoll wäre ja das aktualisieren entsprechender readings bei erhalt der json antwort.
eventuell kommt es aber zu einem unerwünschten "toggeln" der notify readings, wenn während dem löschen im hintergrund bereits ein zyklisches pollen aktiv ist.


Zitat von: JoWiemann am 17 Februar 2025, 15:28:12mit der home.js komme ich so nicht weiter. Ein Testaufbau mit einer FritzOS Version < 8.00 und einer alten FB dauert noch. Ich weiß noch nicht, wann ich für den Aufwand Zeit finde.
keine hektik, bei mir läuft es bereits wie gewünscht.  8)


gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

JoWiemann

Hallo,

ich habe jetzt eine erste größere Beta unter: https://forum.fhem.de/index.php?msg=1334488 bereitgestellt.

Vielen Dank für die Idee und die Unterstützung. Über weitere Tests mit der neuen Beta würde ich mich freuen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html