[gefixed] Heutiges CUL_HM update defekt

yersinia · 13 Januar 2019, 20:01:56

Zitat von: curt am 13 Januar 2019, 19:51:02
@yersinia Meine Anmerkungen bezogen sich auf mein Vorgehen. Hier konkret: Händische, von mir gewollt ausgelöste Handlungen. Vielleicht insofern missverständlich formuliert.

Für mich nicht missverständlich, hab das genauso interpretiert wie geschrieben.

Ich frag mich nur, ob das Update dann automatisch ein save durchführt und damit eventuell bei dem ein oder anderen etwas zerlegt. :/
Was bei dem meisten Update vernünftig zu sein scheint, kann in ~1% aller Fälle die Config zerstören....ist allerdings nur eine Vermutung.

Ich bin froh, dass man den vor-Update-Stand wiederherstellen kann, und das ist auch recht gut dokumentiert.

Und für FOSS funktioniert FHEM für einen bleeding Anfänger mMn sehr gut und ist einfach zu bedienen.

LuckyDay · 13 Januar 2019, 20:24:04

ZitatIch frag mich nur, ob das Update dann automatisch ein save durchführt

Nein!

Es wird deine vorhandene fhem.cfg kopiert nach /opt/fhem/restoreDir....
bevor immer neue Vermutungen aufgestellt werden, könnte man es auch mal testen...

krannich · 13 Januar 2019, 23:33:06

Hallo zusammen,

ich bin wieder auf die Version 10_CUL_HM 18170 und HMConfig 18171 zurückgegangen.
Hatte massive Probleme mit "Missing Acks" seit dem Update heute.
Im Einsatz Busware SCC.

Viele Grüße
Dennis

curt · 13 Januar 2019, 23:40:49

@krannich

Zitat von: krannich am 13 Januar 2019, 23:33:06
Hatte massive Probleme mit "Missing Acks" seit dem Update heute.

Das ist hier aber schon eine Mitmach-Veranstaltung. Dem Maintainer @martinp876 würde vermutlich sehr helfen, wenn Du das nicht allgemein schreibst, sondern konkret mit Logauszügen, lists usw. zeigen würdest.

curt · 14 Januar 2019, 00:29:50

leicht OT.

Zitat von: fhem-hm-knecht am 13 Januar 2019, 20:24:04
ZitatIch frag mich nur, ob das Update dann automatisch ein save durchführt
Nein!

Der Weg zur Hölle ist mit starken Sprüchen gepflastert.

Ich zeige Dir mal ein Beispiel, wie man das unabsichtlich eine Stunde später hinkriegt: @rudolfkoenig hatte man ganz nebenbei [es ging um Benzinpreise] gezeigt, wie man die Sortierung mehrerer Tankstellen an Hand des aktuellen Preises baut. Das bedeutet aber auch, dass FHEM immer mal rumquengelt, dass die veränderte conf zu speichern sei. Da klicke ich quasi blind drauf.

Anderes Beispiel:
Vermittels

Code Auswählen

define Lichterkette_an1 at *{sunset(0,"15:00","21:00")} set Stecker_02 on
define Lichterkette_aus1 at *00:18:00 set Stecker_02 off

lasse ich automatisch mehrere Dinge schalten.

Die "on"-Konstruktion frisst irgendwer stochastisch aus der fhem.cfg. Ich habe nicht die geringste Ahnung, wer das ist, was da passiert. (In diesem Thread führt das zu weit - aber hab mal bitte eine Idee, wie ich das denn nun wieder debugge.)

Ich erwähne das, weil es sehr wohl mehrere Optionen gibt, die fhem.cfg zu schreiben. Die erste ist, es aus fachlich anderen Gründen zu tun; die HM-Änderung ist dann Seiteneffekt. Die zweite ist magisches Zaubersalz.

Mihca · 14 Januar 2019, 08:48:08

Zur Info: Mit dem heutigen Update

Code Auswählen

2019.01.14 08:35:11 1: UPD FHEM/HMConfig.pm

taucht die die folgende Fehlermeldung auf:

Code Auswählen

2019.01.14 08:35:51 1: PERL WARNING: Useless use of a variable in void context at FHEM/HMConfig.pm line 339, <$fh> line 308.

Alle Geräte funktionieren einwandfrei.

MfG
Achim

LuckyDay · 14 Januar 2019, 09:00:18

ZitatCode: [Auswählen]
Autor: curt

define Lichterkette_an1 at *{sunset(0,"15:00","21:00")} set Stecker_02 on
define Lichterkette_aus1 at *00:18:00 set Stecker_02 off

lasse ich automatisch mehrere Dinge schalten.

Die "on"-Konstruktion frisst irgendwer stochastisch aus der fhem.cfg. Ich habe nicht die geringste Ahnung, wer das ist, was da passiert. (In diesem Thread führt das zu weit - aber hab mal bitte eine Idee, wie ich das denn nun wieder debugge.)

wahrscheinlich (sicher) hast du den at 1 malig angelegt und dadurch steht er in der fhem.save drinn.
und nachträglich auf wiederkehrend geändert (*)
normales verhalten.

den saveconfig Knopf kann man auch abschalten, mir ist es auch 1 mal passiert dass ich im falschen Moment draufgedrückt habe.

martinp876 · 14 Januar 2019, 19:59:40

Das mit dem Save nach dem update könnt ihr einfach testen, wie fhem-hm-knecht beschrieben hat.

Ebenso kann man das fhem.cfg wieder einkopieren

Die Meldung aus HMconfig ist berechtigt aber absolut gefahrlos.

Die Meldung Zeile /opt/fhem//FHEM/10_CUL_HM.pm line 7677 sollte auch nichts machen. Du kannst aber einmal ein

Code Auswählen

get hm param -d model subType mId .mId
schicken. (attachement wäre sinnvoll). Jedes Device sollte ein Model, SubType und mId haben. Die .mId ist neu.

Nun wüden mich noch die missingacks interessieren. Ich haben keine, sonst hätte ich nicht gepostet - klar. Welche Devices? welches IO? Ist IODef oder die vccu korrekt eingestellt?

Warlock_2016 · 14 Januar 2019, 21:42:18

Hallo Zusammen,
ich habe auch auf meinem Raspberry einen Busware SCC mit Homematic Geräten laufen.

Nach meinem Update sind alle Homematic Geräte nicht mehr gepaired bzw. lassen sich nicht mehr ansprechen.

Wenn ich ich erneut "set hmpairForSec" 120 tätige und bei meinen Geräten den "Config Schalter" drücke werden alle wieder gepaired und man kann die Geräte über FHEM ansprechen.

Wenn man aber FHEM durchstartet und die Geräte erneut steuern möchte, bekommt immer noch die Fehlermeldung am Beispiel der Rolladensteuerung angezeigt.

Unknown argument down, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk regBulk regSet templateDel
Irgendwie hält FHEM das PAIRING nicht

Muss man bei den Homematic Geräten neue Attributen mitgeben aufgrund des Updates?

Hat jemand einen Tip?

Gruss,
Markus

curt · 15 Januar 2019, 03:16:36

Wir sind mit diesem Beitrag schwer offtopic. Bitte ggf. auslagern!

Zitat von: fhem-hm-knecht am 14 Januar 2019, 09:00:18
Zitat
define Lichterkette_an1 at *{sunset(0,"15:00","21:00")} set Stecker_02 on
define Lichterkette_aus1 at *00:18:00 set Stecker_02 off

Die "on"-Konstruktion frisst irgendwer stochastisch aus der fhem.cfg. Ich habe nicht die geringste Ahnung, wer das ist, was da passiert. (In diesem Thread führt das zu weit - aber hab mal bitte eine Idee, wie ich das denn nun wieder debugge.)

wahrscheinlich (sicher) hast du den at 1 malig angelegt und dadurch steht er in der fhem.save drinn.
und nachträglich auf wiederkehrend geändert (*)
normales verhalten.

Nein.
Es gibt drei derartige Konstruktionen. Die habe ich aus dem Wiki abgeschrieben und in fhem.cfg reingeworden, vor über einem Jahr. (Jaja, sag nix. Nie fhem.cfg anfassen.) Die taten mehr als ein Jahr richtig gut.

Seit -ich weiß nicht- einer Woche wird immer mal wieder der erste Eintrag (anschalten) in fhem.cfg weggefressen. Ja klar, dadurch, dass ich speichere.

Hab bitte lieber eine Idee, wie ich den Verursacher der Löscherei ausfindig mache. Das kann so ja nicht bleiben.

Omega · 15 Januar 2019, 10:05:51

Ich habe heute auch ein Update durchgeführt mit folgendem Ergebnis:
Nach dem ,,shutdown restart" hatte ich für jedes HM-Device die Meldung ,,unknown attribute .mId." im Log.
Daraufhin habe ich ein ,,save" ausgeführt und noch einmal einen ,,shutdown restart".
Die Meldungen ,,unknown attribute .mId." waren jetzt verschwunden.
Ein configCheck bring jetzt allerdings erstmalig Fehlermeldungen bzgl. meiner Rauchmelderteams

Code Auswählen


PairedTo missing/unknown
    Rauchmelder
    Rauchmelder_2

Ich habe jetzt einfach mal ein

Code Auswählen


get hm param -d model subType mId .mId

durchgeführt mit folgendem Ergebnis:

Code Auswählen


entity              	: model                	| subType              	| mId                  	| .mId             
...
    OG.Naehen.Wandthermostat	: HM-TC-IT-WM-W-EU	| thermostat     	| 00AD           	|  -             
    RM_Dachboden        	: HM-SEC-SD      	| smokeDetector  	| 0042           	|  -             
    RM_Flur_OG          	: HM-SEC-SD      	| smokeDetector  	| 0042           	|  -             
    RM_Flur_Schlafzimmer	: HM-SEC-SD      	| smokeDetector  	| 0042           	|  -             
    RM_Heizungskeller   	: HM-SEC-SD      	| smokeDetector  	| 0042           	|  -             
    RM_Kellerflur_Heizung	: HM-SEC-SD-2    	| smokeDetector  	| 00AA           	|  -             
    RM_OG.Jami          	: HM-SEC-SD-2    	| smokeDetector  	| 00AA           	|  -             
    RM_OG.Kinder        	: HM-SEC-SD-2    	| smokeDetector  	| 00AA           	|  -             
    RM_Schlafzimmer     	: HM-SEC-SD-2    	| smokeDetector  	| 00AA           	|  -             
    RM_Vorratskeller    	: HM-SEC-SD-2    	| smokeDetector  	| 00AA           	|  -             
    RM_Werkzeugkeller   	: HM-SEC-SD-2    	| smokeDetector  	| 00AA           	|  -             
    Rauchmelder         	: virtual_1      	|  -             	|  -             	|  -             
    Rauchmelder_2       	: virtual_1      	|  -             	|  -             	|  -             
    SW.motion.Aussen    	: HM-LC-SW2-FM   	| switch         	| 0009           	|  -             
...
    vccu                	: CCU-FHEM       	| virtual        	| FFF0           	|  -

Vielleicht hat es ja etwas zu bedeuten, dass die Rauchmelderteams keine mId haben?
Was muss ich tun (möglichst außer ,,restore"), um wieder ein fehlerfreies System zu haben?

LG
Holger

Beta-User · 15 Januar 2019, 10:18:02

Zitat von: curt am 15 Januar 2019, 03:16:36
Wir sind mit diesem Beitrag schwer offtopic. Bitte ggf. auslagern!
[...]
Hab bitte lieber eine Idee, wie ich den Verursacher der Löscherei ausfindig mache. Das kann so ja nicht bleiben.

Fang' doch selber einen entsprechenden Beitrag an, kannst ja hier verlinken. Als Verdächtigen würde ich mal das alexa-Modul ansehen. Schau mal bei den Wetter-Diskussionen nach, da gab es auch erst den Verdacht, dass eine der neuen API's schuld gewesen wäre, dass plötzlich ohne erkennbaren Grund Zeilen in der cfg hops gegangen sind... Vielleicht ist es ja bei dir ähnlich?

Zitat von: curt am 15 Januar 2019, 03:16:36
Die habe ich aus dem Wiki abgeschrieben und in fhem.cfg reingeworden, vor über einem Jahr. (Jaja, sag nix. Nie fhem.cfg anfassen.)

Weiter OT: Auch wenn manche gerne files händisch editieren, man kann das auch ganz gut über den RAW-Import machen, und die Kombination von Ein- und Ausschalten kann man u.a. auch in einem Weekdaytimer realisieren.

Omega · 15 Januar 2019, 10:51:55

Es wird noch etwas mysteriöser...
Gehe ich auf die Detailseite von HMinfo und löse dort über den Button ein

Code Auswählen

get hm configCheck aus, bekomme ich die Fehlermeldung wie etwas weiter oben beschrieben.

Führe ich

Code Auswählen

get hm configCheck in der FHEM-Kommandozeile aus, bekomme ich in Summe 2 Meldungen, die sich aber überlagern.
Zuunterst liegt ein Fenster mit "OK", darüber schiebt sich aber sehr schnell ein weiteres Fenster mit der oben beschriebenen Fehlermeldung.

JWRu · 15 Januar 2019, 15:19:40

Wenn ich das so lese, gilt für mich immer noch "Finger weg von einem Update".

The-Holgi · 15 Januar 2019, 17:17:27

Hallo,
erstmal Danke für das neue update.
Habe jedoch nach update von HMConfig.pm 18185 auf HMConfig.pm 18237 folgende Meldung im logfile:

Code Auswählen

PERL WARNING: Useless use of a variable in void context at FHEM/HMConfig.pm line 339, <$fh> line 603
Es funktioniert aber alles so wie es soll, soweit ich das nach einem kurzen check feststellen konnte.

Gruß Holger