Probleme nach Update auf aktuelle Version configdb

Begonnen von sledge, 07 Oktober 2017, 18:19:00

Vorheriges Thema - Nächstes Thema

sledge

Hi,

seit gut zwei Jahren betreibe ich eine (mittelgroße?) FHEM-Installation. Nach längerer Zeit habe ich heute mal wieder ein update angestoßen. Vorher noch die Voraussetzungen geprüft (speziell: configdb) - alles klar.

update durchgeführt - keine Fehlermeldungen im log. Also behrzt ein shutdown restart eingegeben und gewartet.

FHEM startet wie immer - nur fehlt meine komplette Heizungsanlage (läuft bei mir mit PWM / PWMR). Also ein Blick ins log und siehe da:


2017.10.07 17:39:01 2: Perfmon: ready to watch out for delays greater than one second
2017.10.07 17:39:07 3: WEB: port 8083 opened
2017.10.07 17:39:07 3: WEBphone: port 8084 opened
2017.10.07 17:39:07 3: WEBtablet: port 8085 opened
2017.10.07 17:39:08 2: eventTypes: loaded 6777 events from ./log/eventTypes.txt
2017.10.07 17:39:08 3: Opening TK.KG.lacrosse.JL device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2017.10.07 17:39:08 3: Setting TK.KG.lacrosse.JL serial parameters to 57600,8,N,1
2017.10.07 17:39:09 3: TK.KG.lacrosse.JL device opened
2017.10.07 17:39:09 3: Opening TK.KG.pca301.JL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01TSCH-if00-port0
2017.10.07 17:39:09 3: Setting TK.KG.pca301.JL serial parameters to 57600,8,N,1
2017.10.07 17:39:10 3: TK.KG.pca301.JL device opened
2017.10.07 17:39:10 3: WK.KG.LF: I/O device is TK.KG.pca301.JL
2017.10.07 17:39:11 3: DbLog dblog: Creating Push-Handle to database mysql:database=fhem;host=hal;port=3306 with user xyz
2017.10.07 17:39:11 3: DbLog dblog: Push-Handle to db mysql:database=fhem;host=hal;port=3306 created
2017.10.07 17:39:11 3: PWM Define FBH.COMF.PWM
2017.10.07 17:39:11 2: called PWM_Attr(set,FBH.COMF.PWM,room,<Heizung>)
2017.10.07 17:39:11 2: called PWM_Attr(set,FBH.COMF.PWM,valveProtectIdlePeriod,<20>)
2017.10.07 17:39:11 2: called PWM_Attr(set,FBH.COMF.PWM,verbose,<1>)
2017.10.07 17:39:11 3: TE.NN.LF: I/O device is TK.KG.pca301.JL
2017.10.07 17:39:12 3: Opening WZ.EG.CUL device 192.168.0.52:2323
2017.10.07 17:39:12 3: WZ.EG.CUL: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2017.10.07 17:39:12 3: WZ.EG.CUL device opened
2017.10.07 17:39:12 2: Switched WZ.EG.CUL rfmode to MAX
2017.10.07 17:39:12 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2017.10.07 17:39:13 3: Opening FZ.ELW.CUL device 192.168.0.53:2323
2017.10.07 17:39:13 3: FZ.ELW.CUL: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2017.10.07 17:39:13 3: FZ.ELW.CUL device opened
2017.10.07 17:39:13 2: Switched FZ.ELW.CUL rfmode to MAX
2017.10.07 17:39:13 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2017.10.07 17:39:14 3: PWMR_Define EZ.EG.PWMR: Unknown sensor device EZ.EG.LF specified
2017.10.07 17:39:14 1: define EZ.EG.PWMR PWMR FBH.COMF.PWM 1 EZ.EG.LF EZ.EG.FBH  dummy 1:0.8:0.4,5:0.5,10: EZ.EG.PWMR: Unknown sensor device EZ.EG.LF specified
2017.10.07 17:39:14 3: PWMR_Define OF.ELW.PWMR: Unknown sensor device OF.ELW.LF specified
2017.10.07 17:39:14 1: define OF.ELW.PWMR PWMR FBH.COMF.PWM 1 OF.ELW.LF OF.ELW.FBH  dummy 1:0.8:0.4,5:0.5,10: OF.ELW.PWMR: Unknown sensor device OF.ELW.LF specified
2017.10.07 17:39:14 3: PWMR_Define BK.OG.PWMR: Unknown sensor device BK.OG.LF specified
2017.10.07 17:39:14 1: define BK.OG.PWMR PWMR FBH.COMF.PWM 1 BK.OG.LF BK.OG.FBH  dummy 1:0.8:0.4,5:0.5,10: BK.OG.PWMR: Unknown sensor device BK.OG.LF specified
2017.10.07 17:39:14 3: PWMR_Define AN.OG.PWMR: Unknown sensor device AN.OG.LF specified
2017.10.07 17:39:14 1: define AN.OG.PWMR PWMR FBH.COMF.PWM 1 AN.OG.LF AN.OG.FBH dummy 1:0.8:0.4,5:0.5,10: AN.OG.PWMR: Unknown sensor device AN.OG.LF specified
2017.10.07 17:39:14 3: PWMR_Define BE.OG.PWMR: Unknown sensor device BE.OG.LF specified
2017.10.07 17:39:14 1: define BE.OG.PWMR PWMR FBH.COMF.PWM 1 BE.OG.LF BE.OG.FBH dummy 1:0.8:0.4,5:0.5,10: BE.OG.PWMR: Unknown sensor device BE.OG.LF specified
2017.10.07 17:39:14 3: PWMR_Define DI.EG.PWMR: Unknown sensor device DI.EG.LF specified
2017.10.07 17:39:14 1: define DI.EG.PWMR PWMR FBH.COMF.PWM 1 DI.EG.LF DI.EG.FBH.str dummy 1:0.8:0.4,5:0.5,10: DI.EG.PWMR: Unknown sensor device DI.EG.LF specified
2017.10.07 17:39:14 3: PWMR_Define DI.ELW.PWMR: Unknown sensor device DI.ELW.LF specified
2017.10.07 17:39:14 1: define DI.ELW.PWMR PWMR FBH.COMF.PWM 1 DI.ELW.LF DI.ELW.FBH dummy 1:0.8:0.4,5:0.5,10: DI.ELW.PWMR: Unknown sensor device DI.ELW.LF specified
2017.10.07 17:39:14 3: PWMR_Define FZ.ELW.PWMR: Unknown sensor device FZ.ELW.LF specified
2017.10.07 17:39:14 1: define FZ.ELW.PWMR PWMR FBH.COMF.PWM 1 FZ.ELW.LF FZ.ELW.FBH dummy 1:0.8:0.4,5:0.5,10: FZ.ELW.PWMR: Unknown sensor device FZ.ELW.LF specified
2017.10.07 17:39:14 3: PWMR_Define KC.OG.PWMR: Unknown sensor device KC.OG.LF specified


Sieht für mich so aus, als ob er die notwendigen Devices .*.LF nicht gefunden hat, als er die PWMR-devices anlegen wollte.

Also ein configdb info eingegeben, damit ich die Situation erstmal bewerten kann. Das war vor rund 20 Minuten - und der Kringel dreht sich. Also einmal rebootet und nochmal - gleiches Symptom.

Hat jemand ähnlich Erfahrungen beim Update gemacht? Vorher war die DB durchaus performant (mysql auf dem gleichen Rechner, 4GB RAM) - jetzt geht bei der Abfrage garnichts mehr.

Greife ich parallel mit heidisql auf die DB zu, komme ich an die Daten - scheint also nicht korrupt zu sein - nur die Performance ist eher "unterirdisch".

Soll ich einfach auf eine ältere Version der config zurückgehen? Oder kann ich gefahrlos auf eine äöltere Version von configdb zurückgehen?

Freue mich über input.

Gruß,Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

sledge

FollowUp:

Wenn ich ein configdb list <device> eingebe, werden alle Devices gefunden - sowohl die vorher angemahnten .*.LF-devices also auch doe .*.PWMR-devices

Clueless... weil mit dieser Info bringt mir auch ein recover vermutlich nichts?

Freue mich über Info.

Gruß,

Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Benni

Das legt nahe, dass es nicht an configDB liegt, was ich mir schon dachte.

Es können wohl aus irgendeinem Grund benötigte Devices nicht angelegt werden.
Das sollte sich eigentlich im Log finden lassen. Ggf. mal verbose hochdrehen.

Dass ein configdb info bei dir so lange dauert, liegt übrigens wahrscheinlich daran, dass du viel zu viele Versionen in der Datenbank aufbewahrst.

Das lässt sich mit configdb attr maxversions entsprechend begrenzen.

betateilchen

Du suchst an der falschen Stelle. configDB ist nicht Dein Problem., sondern irgendein anderes Modul, das Du verwendest und das nicht (mehr?) so arbeitet, wie Du Dir das vorstellst.

"configdb list" liefert übrigens die Konfigurationsdaten aus der Datenbank, nicht die Daten der aktuell laufenden FHEM Installation. Wenn also beim FHEM Start irgendwas schiefgeht und devices nicht angelegt werden können, nützt Dir ein "configdb list" überhaupt nichts.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

sledge

Das mit den "viel zu vielen" Versionen - touché. Das bereinige ich gleich mit einem Reorg und begrenze es dann mit dem Setzen des Attributes. Thx for that.

Ich habe jetzt die Devices neu angelegt gemäß den Befehlen, die aus dem "configdb list...." rausgekommen sind... dennoch merkwürdig.

Erst reorg, dann begrenzen, dann ein shutdown restart. Mal sehen, was passiert.

Danke bis hierher.

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

sledge

So - update.

Was auch immer das Problem war - ob configdb oder ein anderes Modul - der "reorg" hat Abhilfe geschaffen. Alle Devices werden jetzt bei einem shutdown restart sauber angelegt. Ggfs ein Timing Problem, falls die DB zu groß geworden ist? Dunno.

Durch configdb maxversion 40 sollte da in Zukunft ein Riegel vorgeschoben sein.

Danke für den schnellen Support/ Fingerzeig in die Richtung.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...