72_FRITZBOX.pm ab Version 07.57.10

Begonnen von JoWiemann, 05 Januar 2024, 10:39:57

Vorheriges Thema - Nächstes Thema

Jamo

Zitat von: JoWiemann am 11 April 2024, 14:02:16Hallo Jamo,

ein Intervall mit 60 Sekunden ist schon sehr ambitioniert. Ich habe irgendwann das TimeOut für den nonBlocking Prozess von 35 auf 50 Sekunden hoch gesetzt. Es gab hier viele Meldungen für einen TimeOut beim Hochfahren von Fhem. Ich checke Heute sowieso eine neue Version ein. In der habe ich das Attribut nonblockingTimeOut dann mal um weitere Auswahlzeiten ergänzt. Dort kannst Du dann 35 Sekunden auswählen.

Grüße Jörg
Hallo Jörg,
sowohl 10/20/35/50/55 Sekunden für das attr nonblockingTimeOut (Bei Interval 60) funktionieren nicht, alle Werte führen früher oder später dazu, das die Readings bis auf die oben beschriebenen Ausnahmen nicht mehr aktualisiert werden.

Bezüglich des "Intervall mit 60 Sekunden ist schon sehr ambitioniert" -> das hat bei mir seit mindestens 6 Jahren mit allen Versionen des 72_FRITZBOX.pm problemlos funktioniert. Es geht erst seit den letzten 3 Versionen nicht mehr, ich glaube version 12b oder so, als wegen einem manuellem edit der fhem.cfg der Neustart/InitialisierungStart Prozess verändert wurde.

Nun gut, was ich aber nicht verstehe, ist das wenn der timeout überschritten wird, und der FRITZBOX_Readout_Run_Web nicht durchgeführt werden kann, dann muss doch abgebrochen und ein neuer Prozess gestartet werden. Aber aus meinem Log 5 oben geht hervor, das der der "Old readout process still running" ist, und erst durch ein manuelles update gekillt wird

Laut FHEMWIKI fuer den BlockingCall (den ich im code gefunden hab, soll doch im Falle eines Abruchs durch einen überschrittenen Timeout eine abortFn aufgerufen werden, womit man den alten Prozess dann killen könnte und dann einen neuen FRITZBOX_Readout_Run_Web prozess starten könnte?

Beste Grüsse, Jamo

Nochmal der Log 5 von Oben2024.04.11 07:06:18 4:[FritzBox | 7590 | 154.07.57 | Readout_Start.2918] - EXPANDED:Skip fork process FRITZBOX_Readout_Run_Web
2024.04.11 07:07:18 4:[FritzBox | 7590 | 154.07.57 | Readout_Start.2918] - EXPANDED:Skip fork process FRITZBOX_Readout_Run_Web
2024.04.11 07:08:18 4:[FritzBox | 7590 | 154.07.57 | Readout_Start.2918] - EXPANDED:Skip fork process FRITZBOX_Readout_Run_Web
-> hier ein manuelles set FritzBox update gemacht
2024.04.11 07:09:02 3:[FritzBox | 7590 | 154.07.57 | Set.1080] - BASIC:set FritzBox update
2024.04.11 07:09:02 4:[FritzBox | 7590 | 154.07.57 | Readout_Start.2902] - EXPANDED:Old readout process still running. Killing old process HASH(0x55970e427b80)
2024.04.11 07:09:02 4:[FritzBox | 7590 | 154.07.57 | Readout_Start.2915] - EXPANDED:Fork process FRITZBOX_Readout_Run_Web
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

JoWiemann

Hallo Jamo,

danke für die Informationen. Grundsätzlich habe ich eigentlich nichts an der nonBlocking Logik geändert. Ich werde versuchen das nachzustellen. Da wir aktuell einen Immobilienwechsel durchführen kann das etwas dauern.

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

Jamo

Zitat von: JoWiemann am 12 April 2024, 20:14:36Hallo Jamo,

danke für die Informationen. Grundsätzlich habe ich eigentlich nichts an der nonBlocking Logik geändert. Ich werde versuchen das nachzustellen. Da wir aktuell einen Immobilienwechsel durchführen kann das etwas dauern.

Grüße Jörg
Hallo Jörg,
danke und keine Eile, ich bin jetzt erstmal auf die 07.57.12 Beta (nicht die 07.57.12b) zurück,
das funktioniert für mich. Viel Erfolg beim Immobilienwechsel und schönes Wochenende!
Beste Grüsse!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Jamo

Hallo Joerg,
nur zur Info, die Version "07.57.12 Beta" vom 2024-02-01 zeigt das Verhalten nicht. Also die funktioniert problemlos. Ich habe mal einen diff gemacht, und in der Tat am nonblocking und am Readout scheint es keine Unterschiede zu geben. Beste Grüsse!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

JoWiemann

#79
Zitat von: Jamo am 13 April 2024, 09:53:48Hallo Joerg,
nur zur Info, die Version "07.57.12 Beta" vom 2024-02-01 zeigt das Verhalten nicht. Also die funktioniert problemlos. Ich habe mal einen diff gemacht, und in der Tat am nonblocking und am Readout scheint es keine Unterschiede zu geben. Beste Grüsse!

Hallo Jamo,

Danke für die Analyse. Ich habe die Fehlerbehandlung umgebaut. Vielleicht liegt da noch der Wurm drin. Ziel war es, dass ein Fehler nicht mehr alle geholten Daten verwirft. Muss ich mir dann mal in Ruhe ansehen.

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

Seli

Ich kann die Beobachtung von Jamo bestätigen. Ich benutze ebenso die mac-Readings für die Anwesenheitserkennung seit Jahren problemlos. Nach einem "update" werden die readings zunächst minütlich aktualisiert, aber irgendwann bricht es dann ab. Dieses Verhalten ist relativ neu.

Grüße,
Seli
Raspberry Pi 3, FHEM 5.8
CUL868 V3 (FS20/IT): FHT80TF|PIRI|PIRI-2|TFK|S4A-2|ST|SU|S8|HMS 100 WD|IT-1500|GRR-3500
HomeMatic HMLAN_UART: HM-CC-RT-DN|HM-SEN-MDIR-O|HM-SEC-SC-2|HM-TC-IT-WM-W-EU|HM-LC-SW4-PCB 4|HM-WDS-OTH|HM-OU-LED16|HM-RC-4-3
JeeLink v3c, Rademacher duoFern, Philips Hue

juemuc

#81
Hallo zusammen,

ich kann dies zum Glück nicht bestätigen. Ich habe event-on-change mit folgenden Werten definiert: "state,mac.*". Wenn dies nicht mehr funktionieren würde, würden andere Geräte nicht ein bzw. ausgeschaltet werden. Es würde also recht schnell auffallen  8) 

Ich nutze eine FB6690. Habt Ihr ggf. temporär event-on-change 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).

Jamo

#82
Hallo Seli,
gut das ich nicht der einzige bin, bei dem das Problem auftritt.

Hallo Juergen,
nein, wir haben event-on-change nicht geloescht, das habe ich gar nicht gesetzt. Ich spreche davon das der Zeitstempel der spezifischen Readings nicht mehr geupdated wird. Nach einem Web refresh sollte auch der Zeitstempel geaendert werden, auch wenn eoc nicht gesetzt ist. Ich brauche das event nicht, aber das reading sollte aktuell sein, das ich den status des Readings abfrage.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

juemuc

Hallo Jamo,

bei mir wird auch der Zeitstempel aktualisiert. Sehr merkwürdig. Ist für Jörg das Finden der NAdel im Heuhaufen.
Welche Fritzbox nutzt ihr und welches Intervall habt Ihr eingestellt. Ich nutze 120sec.

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).

Jamo

Zitat von: juemuc am 14 April 2024, 22:14:21Hallo Jamo,

bei mir wird auch der Zeitstempel aktualisiert. Sehr merkwürdig. Ist für Jörg das Finden der NAdel im Heuhaufen.
Welche Fritzbox nutzt ihr und welches Intervall habt Ihr eingestellt. Ich nutze 120sec.

Viele Grüße
Jürgen
Steht alles oben https://forum.fhem.de/index.php?msg=1310370

Joerg hat schon angedeutet, das es evtl an der neuen Fehlerbehandlung liegt, wo er vermeiden wollte, das im Fehlerfall Readings verworfen werden. Das warte ich jetzt ab.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Christian.

Ich habe nicht die gesamte Diskussion verfolgt, glaube aber vom zuletzt beschriebenen Problem betroffen zu sein. Ich möchte Infos beisteuern, um das Problem einzukreisen:

  • Mit dem Modul in Version 07.57.13a (2024-04-11 / SVN-Revision 28783) werden keine Readings aktualisiert.
  • Ein Downgrade auf Version 07.57.12c (2024-04-03 / SVN-Revision 28743) schafft Abhilfe.
  • Die Umgebung (FHEM-Installation inkl. Konfiguration) ist dabei unverändert.

Die dazwischen liegende Version 07.57.13 (2024-04-09 / SVN-Revision 28778) habe ich nicht getestet.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

mähschaf

Hallo und guten Morgen,

ich weiß nicht, ob es weiterhilft oder eher verwirrt, aber folgende Info:

Der Fehler trat bei mir nach einem Update gestern auf, jedoch nur bei den beiden 7390, nicht bei meiner 7490?!?

Ein Downgrade hat geholfen. Timeout habe ich bei keiner Box gesetzt.

Schönen Sonntag und erfolgreichen Immobilienwechsel :)

Martin

RappaSan

Habe soeben festgestellt, daß Presence im event-Modus ebenfalls nicht mehr funktioniert.
Betroffen ist
$Id: 72_FRITZBOX.pm 28783 2024-04-11 12:13:32Z jowiemann.

Mit der Version
$Id: 72_FRITZBOX.pm 28642 2024-03-12 17:00:48Z jowiemann
läuft alles wie gewohnt.

Christian.

Zitat von: Christian. am 21 April 2024, 09:33:44
  • Ein Downgrade auf Version 07.57.12c (2024-04-03 / SVN-Revision 28743) schafft Abhilfe.

Das muss ich korrigieren. Nach ca. 10 Stunden werden auch mit Revision 28743 keine Werte mehr geliefert. Ich wechsle jetzt auf Version 07.57.11b (2024-02-08 / SVN-Revision 28495).
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Ryker

#89
Bei mir funktioniert seit vor Kurzem die Presenzerkennung nicht mehr.
Sind die Geräte online, dann ist alles OK. Sind die Geräte offline, dann bekomme ich jetzt im ReadingsProxy anstelle von "inactive" ein "inactive: 192.168.178.x". Das läßt sich dann dann im PRESENCE-Module dann nicht mehr auswerten in der Art:
function {ReadingsVal("State_Handy_Conni","state","") ne "inactive" ? 1:0}
weil eben nun die IP-Adresse noch hinten dran hängt. Die will ich auch nicht statisch mit einbauen, weil die kann sich auch mal ändern.

Ich hab mir zwar jetzt über einen dirty-hack den Wert im Readingsproxy wieder auf "inactive" gesetzt, wenn das Gerät inactive ist, indem ich dort ein
attr State_Handy_Conni valueFn {($VALUE =~ m/inactive/)?"inactive":$VALUE}
eingebaut habe.

Aber hat jemand eine Idee wo und wie man an dem Fritzbox-Modul wieder das alte verhalten einstellen kann ?