[BUG] heutiges Update 10_CUL_HM.pm

Begonnen von raiderxxl, 20 November 2017, 09:07:10

Vorheriges Thema - Nächstes Thema

raiderxxl

Hi ich habe folgende fehler nach dem Update... Ihr auch?

2017.11.20 08:51:38 1: reload: Error:Modul 10_CUL_HM deactivated:
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at ./FHEM/10_CUL_HM.pm line 7835, <$fh> line 403.

2017.11.20 08:51:38 0: Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at ./FHEM/10_CUL_HM.pm line 7835, <$fh> line 403.

2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Initialize redefined at ./FHEM/10_CUL_HM.pm line 148, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_updateConfig redefined at ./FHEM/10_CUL_HM.pm line 231, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Define redefined at ./FHEM/10_CUL_HM.pm line 512, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Undef redefined at ./FHEM/10_CUL_HM.pm line 568, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Rename redefined at ./FHEM/10_CUL_HM.pm line 587, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Attr redefined at ./FHEM/10_CUL_HM.pm line 635, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_AttrCheck redefined at ./FHEM/10_CUL_HM.pm line 936, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_prtInit redefined at ./FHEM/10_CUL_HM.pm line 954, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_hmInitMsg redefined at ./FHEM/10_CUL_HM.pm line 959, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_hmInitMsgUpdt redefined at ./FHEM/10_CUL_HM.pm line 996, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Notify redefined at ./FHEM/10_CUL_HM.pm line 1024, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_setupHMLAN redefined at ./FHEM/10_CUL_HM.pm line 1040, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Parse redefined at ./FHEM/10_CUL_HM.pm line 1077, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_parseCommon redefined at ./FHEM/10_CUL_HM.pm line 2955, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_m_setCh redefined at ./FHEM/10_CUL_HM.pm line 3507, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_queueUpdtCfg redefined at ./FHEM/10_CUL_HM.pm line 3518, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_parseSDteam redefined at ./FHEM/10_CUL_HM.pm line 3536, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_parseSDteam_2 redefined at ./FHEM/10_CUL_HM.pm line 3597, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_updtSDTeam redefined at ./FHEM/10_CUL_HM.pm line 3658, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_pushEvnts redefined at ./FHEM/10_CUL_HM.pm line 3679, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Get redefined at ./FHEM/10_CUL_HM.pm line 3706, <$fh> line 416.
2017.11.20 08:51:38 1: PERL WARNING: Subroutine CUL_HM_Set redefined at ./FHEM/10_CUL_HM.pm line 3986, <$fh> line 416.


Backup wurde wiederhergestellt die alte Funktioniert wieder...

Grüßle
Pascal
FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

Tedious

Habe ich auch. Bitte setz die Meldung in <code>-Tags, da will keiner seitenweise scrollen...
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

raiderxxl

Gmorsche,

Code war gesetzt hat es aber abgeschnitten da zu lang.. glaub ich... Ich hab es jetzt gekürzt
FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

Tedious

Ich habe jetzt die 10_CUL_HM.pm aud dem Backup wiederhergestellt, in der Installation ersetzt und neu gestartet (shutdown restart). Läuft soweit wieder alles, als Hotfix.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

octek0815

#4
Hier das Selbe. Backup aus dem RestoreDir wieder rein und alles läuft wieder.

Folgende Meldung war im Log zu sehen:

2017.11.20 10:27:12 1: reload: Error:Modul 10_CUL_HM deactivated:
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at ./FHEM/10_CUL_HM.pm line 7835, <$fh> line 118.

2017.11.20 10:27:12 0: Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at ./FHEM/10_CUL_HM.pm line 7835, <$fh> line 118.

Und zwar beim initialisieren von jedem HM Device...

betateilchen

Vielleicht wäre es sinnvoll, den Titel des Threads zu ändern und dort einen Hinweis auf den Bug einzufügen.


[BUG]  heutiges Update 10_CUL_HM.pm
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

raiderxxl

hab ich gemacht...
Danke für den Hinweis...
FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

betateilchen

Wenn man das tut, was die Fehlermeldung als mögliche Lösung bereits vorschlägt:

Zitat
2017.11.20 08:51:38 1: reload: Error:Modul 10_CUL_HM deactivated:
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at ./FHEM/10_CUL_HM.pm line 7835,

funktioniert auch die heutige Modulversion ohne Fehlermeldung.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

raiderxxl

Na Toll, jetzt steh ich ganz schön dumm da, denn ich habe keine Ahnung was das zu bedeuten hat...

Bin Kein Programmierer ... nur Dummer User (in diesem Fall)

Grüßle

Pascal

Zitat von: betateilchen am 20 November 2017, 12:32:11
Wenn man das tut, was die Fehlermeldung als mögliche Lösung bereits vorschlägt:

funktioniert auch die heutige Modulversion ohne Fehlermeldung.
FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

octek0815

Ich denke wir sollten hier Ruhe bewahren.
Als Workaround ist ja immer ein Rollback möglich!

Martin liest bestimmt mit und wird das schon zeitnah fixen.

betateilchen

Zitat von: octek0815 am 20 November 2017, 13:32:58
Ich denke wir sollten hier Ruhe bewahren.

Das denke ich auch. Mein Hinweis oben war auch eher als Hinweis an martin gerichtet ;)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

raiderxxl

FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

fstefan1960

#12
Hiiiilfe!

Hallo, ich habe zwar eine alte 10_CUL_HM.pm wieder eingebaut, aber alle Geräte, die für CUL_HM definiert sind, sind weg und kommen trotz mehrfachen "shutdown restart" s nicht wieder ....

Auch "rereadcfg" bringt nix ...

Evtl. ist meine 10_CUL_HM.cfg zu alt. Kann man irgendwo die letzte funktionierende downloaden?
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

marvin78

Dann hast du vermutlich ein save gemacht. Backup-Config einspielen und alles ist gut.

betateilchen

Zitat von: marvin78 am 20 November 2017, 14:28:26
Backup-Config einspielen und alles ist gut.

oder einfach eine Vorgängerversion aus der configDB zurückholen  :P

Zitat von: fstefan1960 am 20 November 2017, 14:23:22
Evtl. ist meine 10_CUL_HM.cfg zu alt.

so eine Datei ist mir unbekannt...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

LuckyDay

/opt/fhem/restoreDir/2017-11-20

so mal als Tipp , in dem Verzeichnis steht die Vorgänger 10_CUL_HM.pm und die letzte fhem.cfg drin vor update drin.

betateilchen

Zitat von: fhem-hm-knecht am 20 November 2017, 18:48:04
so mal als Tipp , in dem Verzeichnis steht die Vorgänger 10_CUL_HM.pm und die letzte fhem.cfg drin vor update drin.

kommt drauf an, wie man sein update macht ;)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

PieBa

Hallo, für alle, die sich auf dem System eher so rudimentär auskennen wie ich:

Über folgenden Befehl auf der Konsole meines raspi habe ich die alte funktionierende Datei aus dem heutige Backup wiederhergestellt.
Nach einem restart funktioniert wieder alles einwandfrei.

sudo cp /opt/fhem/restoreDir/2017-11-20/FHEM/10_CUL_HM.pm /opt/fhem/FHEM/10_CUL_HM.pm

Kevin

Habe mit erschrecken festgestellt, dass ich leider folgende Einstellung habe:

attr global backup_before_update 0

Kann man irgendwo die "10_CUL_HM.pm" von vor dem Stand von 20.11.2017 beziehen?

raiderxxl

FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

marvin78

Leute: backup_before_update hat nix mit dem restore zu tun. Versionen findet ihr im SVN. Und bitte: Überlegt euch ein Backupkonzept, BEVOR ihr FHEM produktiv einsetzt!

Kevin


Kevin


Backup ist in Form von kompletter ISO der Installation und auch von den Configs aller Versionen vorhanden.

Leider nur nicht innerhalb von restoreDir die pms.... Wie aktiviere ich das? Oder muss ich das jedes Mal manuell ausführen?

Danke

CoolTux

Zitat von: Kevin am 21 November 2017, 10:13:17
Backup ist in Form von kompletter ISO der Installation und auch von den Configs aller Versionen vorhanden.

Leider nur nicht innerhalb von restoreDir die pms.... Wie aktiviere ich das? Oder muss ich das jedes Mal manuell ausführen?

Danke

Device global Attribut backupBeforUpdate oder so ähnlich
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

marvin78

Ist das Attribut restoreDirs bei dir auf 0 gesetzt?

Kevin

ich war blind... ist nun gesetzt:

attr global restoreDirs 1

marvin78

Default wäre 3. Wenn du das Attribut also löscht, werden für die 3 letzten Updates restore Verzeichnisse angelegt.


Wenn es nicht auf 0 war, sollte es auch ohne explizites Setzen funktionieren.

zgadgeter

Ok,
ich brauche Hilfe, bin was diese Sachen angehen noch kompletter Newbie, und ich habe mich nicht genügend mit Backup beschäftigt. Mein letzter Backup is wahrscheinlich vor ca 2 Wochen..kann im Moment nicht nachsehen da ich im Büro bin und habe nur Weboberflaeche Zugriff, und hier auch kein VPN Zugriff auf Zuhause.....ja, ist ein Fehler von mir nicht genügend mich mit Backup zu beschäftigen...
Also, CUL_HM Fehler, und alle HM devices weg.
Bevor ich irgendwas (nochmals) falsch mache, was sollte ich tun? Heute Abend zuhause kann ich genau nach sehen von wann das Backup ist. Sollte ich die CUL_HM.pm von da wieder rüber kopieren? Wenn ja, werden die devices wieder auftauchen oder müssen die wieder Manuel konfiguriert werden?
Fuer freundliche Hilfe waere ich sehr dankbar  :) ;D
NUC FHEM mit vielen Intertechno/FS20/Flamingo schalter
und Busware CUL und nanoCUL

zgadgeter

Zitat von: marvin78 am 21 November 2017, 10:24:17
Default wäre 3. Wenn du das Attribut also löscht, werden für die 3 letzten Updates restore Verzeichnisse angelegt.
Ich habe dieses attribute bei mir nicht gesetzt, bedeutet das das es eigentlich 3 sein muss (default), und somit habe ich drei backups? Kann im Moment nicht nachsehen, bin nicht Zuhause...
NUC FHEM mit vielen Intertechno/FS20/Flamingo schalter
und Busware CUL und nanoCUL

octek0815

Wie wäre es wenn wir hier in diesem Thread beim Thema beliben, und das ist und beleibt vorrangig ein Bug in der 10_CUL_HM.pm.
Andere Probleme wie "falsch eingestellte Backups" oder "gar kein Backup" oder "wie konfiguriere ich FHEM überhaupt" sollten doch lieber in einem neuen oder anderen Thread diskutiert werden.

marvin78

Zumal diese Fragen alle vor einem Problem geklärt sein sollten.


Für alle, die das nicht geklärt haben, gibt es aber natürlich auch schon genug dazu in der Dokum, hier im Forum und im Wiki.

Tedious

#32
Ich fasse mal zusammen, denn sollte alles gesagt sein, und nicht jeder macht sich ja die Mühe mehr als die letzten 2 Beiträge im Thread zu lesen ;)

Variante 1:

/opt/fhem/restoreDir/DATUM - hier findet sich in aller Regel die jeweils letzte Datei die ersetzt wurde. Also von hier aus in /FHEM kopieren. Läuft wieder

Variante 2:

Bei gesetztem attr global backup_before_update 1 in der fhem.cfg liegen im Backup-Vereichnis gepackte Dateien mit den letzten Änderungen. Auch hieraus kann man die "alte" datei extrahieren und nach /FHEM kopieren. Auch dann läuft wieder alles.

Timestamp der Datei ist erstmal wumpe - ob die nun aus dem Juli oder von vorgestern ist - zumindest läuft erst mal wieder alles.

Wer mit der shell nicht klarkommt - sudo apt-get install mc. Das geht auch mit dem Midnight Commander, mehr dazu hier: https://wiki.ubuntuusers.de/Midnight_Commander/

EDIT: kleine Anmerkung: man sollte IMHO das Backup einfach IMMER mitlaufen lassen. Ich sichere immer das letzte stabile Archiv eines Monats auf einen anderen Rechner bzw. NAS. Alle anderen Backups fliegen in die Tonne. Man kann so zumindest jederzeit auf einen stabilen Stand zurück, selbst wenn der Massenspeicher des FHEM-Rechners in die Knie geht läuft eine Neuinstallation in wenigen Minuten wieder wie vor dem Crash.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

betateilchen

Man könnte auch einfach in Zeile 7835 der fehlerhaften Moduldatei das dort enthaltene Wort "defined" löschen, damit alles funktioniert.
Dann braucht man überhaupt nicht mit Rumkopieren, Attributen und Backupstrategien rumkaspern.
Und das funktioniert sogar dann, wenn man den FHEM-eigenen Mechanismus zum Update überhaupt nicht verwendet.



-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

eisman

hi,
damit stellt sich doch die frage, ist es behoben oder nicht,
an Modul-Dateien sollte man wohl weniger etwas ändern.
mir würde sowas nicht gefallen und
vielleicht sollte man ein extra bereich für solche Fehler machen, dann gibt es auch
keine 20 verschiedene bereiche. wo der Fehler und die Lösungen gepostet werden.
gruss
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

marvin78

Zitat von: eisman am 21 November 2017, 15:04:49
etwas ändern.
mir würde sowas nicht gefallen und
vielleicht sollte man ein extra bereich für solche Fehler machen, dann gibt es auch
keine 20 verschiedene bereiche. wo der Fehler und die Lösungen gepostet werden.



Darauf würde ich nicht wetten.

Tedious

Zitat von: betateilchen am 21 November 2017, 14:57:28
Man könnte auch einfach in Zeile 7835 der fehlerhaften Moduldatei das dort enthaltene Wort "defined" löschen, damit alles funktioniert.
Dann braucht man überhaupt nicht mit Rumkopieren, Attributen und Backupstrategien rumkaspern.
Und das funktioniert sogar dann, wenn man den FHEM-eigenen Mechanismus zum Update überhaupt nicht verwendet.

Nix für ungut, aber ich denke mal bei kritischer Betrachtung der Probleme die schon beim Thema Update auftauchen mag der eine oder andere beim Thema Editor ggf überfordert sein. Und, dem angelehnt - es wird immer wieder drauf rumgeritten bloß nicht in der fhem.cfg händisch zu arbeiten, das steht ja fast unter Todesstrafe ;) Wer das überblickt macht das trotzdem ab und an... der editiert auch in der pm herum. Aber einerseits zu fordern bei der cfg die finger vom Editor zu lassen und auf der anderen Seite denn in der .pm rumzuknuffeln ist ein schwieriger Spagat.

IMHO ist es denn zielführender auf die funktionale Version zurück zu gehen und auf einen fix zu warten - die lief eh bei 99% der User problemlos.  Der Maintainer kennt sich nun mal am besten mit dem Code und den Änderungen aus, und nicht selten zieht eine manuelle Änderung andere Probleme hinter sich her. Just my 2 cents ;; 
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

CoolTux

Zitat von: eisman am 21 November 2017, 15:04:49
hi,
damit stellt sich doch die frage, ist es behoben oder nicht,
an Modul-Dateien sollte man wohl weniger etwas ändern.
mir würde sowas nicht gefallen und
vielleicht sollte man ein extra bereich für solche Fehler machen, dann gibt es auch
keine 20 verschiedene bereiche. wo der Fehler und die Lösungen gepostet werden.
gruss

Schau doch einfach ins SVN dort siehst Du ob seit auftauchen des Fehlers das Modul neu eingecheckt wurde.
Am Modul etwas ändern ist ok, so lange man weiß was man tut.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Zitat von: eisman am 21 November 2017, 15:04:49
an Modul-Dateien sollte man wohl weniger etwas ändern.

Wer sagt das? Die Lizenz, unter der die Moduldateien von FHEM stehen, erlaubt und fördert sowas ganz grundsätzlich.

Ausserdem wird eine mögliche Lösung ja von perl selbst schon in der Fehlermeldung selbst vorgeschlagen...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#39
Um nochmal auf den eigentlich Bug zurückzukommen... es handelt sich schlichtweg um ein versionsabhängiges perl-Verhalten.
In der perl Dokumentation steht:

Zitat
Use of defined on aggregates (hashes and arrays) is no longer supported.

Also gibt es gar keine andere Lösung, als die Prüfung per defined() in der genannten Modulzeile zu entfernen.

Und vermutlich tritt das Problem bei martin aufgrund einer älteren perl Version in seiner Entwicklungsumgebung gar nicht auf, sonst hätte er das Modul vermutlich so nicht eingecheckt. Und vermutlich hat er deshalb auch diesen Thread hier noch gar nicht entdeckt...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

eisman

Zitat von: betateilchen am 21 November 2017, 15:25:35
Wer sagt das? Die Lizenz, unter der die Moduldateien von FHEM stehen, erlaubt und fördert sowas ganz grundsätzlich.

hi, du hast da schon recht,

der Rest ist oben schon gesagt, ist halt Internet Problem (ja,nein und vielleicht)
und natürlich kann man in SVN schauen. (Hilft aber nicht jeden)
Oder man schreibt nicht cfg edit=> NEIN include => NEIN und dann mach es selber.

gruss

1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

raiderxxl

Mahlzeit,

kann man den Martin den irgendwie anstupsen?

Grüßle

Pascal
FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

marvin78


Pfriemler

#43
Zitat von: octek0815 am 21 November 2017, 13:13:50
Andere Probleme wie "falsch eingestellte Backups" oder "gar kein Backup" oder "wie konfiguriere ich FHEM überhaupt" sollten doch lieber in einem neuen oder anderen Thread diskutiert werden.

Stimmt. Aber wer ist der Maintainer von "global"? :-)
Die commandref kennt weder restoreDir noch backup_before_update noch exclude_from_update. Das kann doch keine Absicht sein.

Martin übersieht den Thread garantiert nicht. Aber man darf gern eine PM schicken. Aber nicht alle auf einmal.
Dann reagiert er schneller. Hat jemand schon?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

marvin78

Natürlich kennt die Commandref diese Attribute. Man findet sie unter update. Ist der Searchbutton in deinem Browser kaputt? Und wer maintainer von update ist, ist klar. Wofür man den in dem Zusammenhang braucht oder wissen muss, wer das ist, ist mir nicht klar.

Pfriemler

ZitatNatürlich kennt die Commandref diese Attribute. Man findet sie unter update
Aber sie sind unter global einzutragen. Und wenn ich dort nach einer Erklärung für die Attribute suche, finde ich nichts. Dann gehört dort meinetwegen noch ein Link a la "weitere Attributen sind unter "update" beschrieben hin. Der Rest meiner Frage war mit einem manuellen Smilie versehen ... ja natürlich ist klar.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

marvin78

Sie sind deshalb unter update zu finden,weil sie im direkten Bezug darauf verwendet werden. Die Logik ist nicht wirklich falsch oder verquer. Ich habe z.B. direkt dort gesucht. Wobei man in der commandref aus meiner Sicht ohnehin immer die Browsersuche verwenden sollte.

betateilchen

Zitat von: marvin78 am 21 November 2017, 16:51:55
Sie sind deshalb unter update zu finden,weil sie im direkten Bezug darauf verwendet werden.

.. und sie müssen in global gesetzt werden, weil update ein Befehlsmodul ist und damit keine devices erzeugt werden, die überhaupt nur Attribute besitzen könnten.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Pfriemler

#48
Leuts, dass die besagten Attribute logisch zu "update" gehören, ist (mir) klar. Dass sie bei global eingetragen werden (müssen), auch.
Ich habe nur die (offenbar ketzerische) Frage gestellt, warum man die bei einem Device auswählbaren Attribute (konkret: in der Dropdownliste) nicht auch bei der in der Weboberfläche kurz darunter erhältlichen "Device specific help" erklärt bekommt (edit: oder zumindest dort einen Hinweis darauf bekommt) - genau dort greift nämlich die Browsersuche nicht, weil die Erklärung in einem anderen Kapitel der commandref steht und diese dann dort nicht angezeigt wird.

Aber den Kommentaren zu meinen Äußerungen zufolge ist dieses "Versteckspiel"  :) also doch volle Absicht. Nun ja. Dann ist es eben so.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

hier kommt ja richtige weihnachtsstimmung auf.  ;)
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

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Pfriemler

missverstanden zu werden hat bei mir Tradition, das macht mir nix mehr aus.  ;D ;D ;D

Aber ich habe gerade Martin im Forum gesichtet, also kommt er sicher gleich hier vorbei ...  ;D
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

achim-e

Hmm, Mist, bei mir klappt es auch nicht mehr.

Ich habe beide Varianten probiert: zunächst die alte Version aus dem Backup zurück gespielt und dann (nachdem es nicht richtig ging) nochmal ein Update gemacht und die neue Version editiert. Problem: die meisten Devices reagieren nicht mehr.

Wenn ich den configCheck richtig interpretiere, dann hat sich wohl deren Pairing aufgelöst. Ich kopiere hier mal das Ergebnis des configChecks rein:
configCheck done:

missing register list
    Bewegungsmelder_Flur_EG: RegL_00.,RegL_01.
    EG_AR_Kontakt: RegL_00.,RegL_01.
    EG_HW_Kontakt_Seite: RegL_00.,RegL_01.
    EG_HW_Kontakt_vorneR: RegL_00.,RegL_01.
    EG_Haustuer_Kontakt: RegL_00.,RegL_01.
    EG_KU_Kontakt: RegL_00.,RegL_01.
    EG_Rauchmelder_Flur: RegL_00.
    EG_WC_Kontakt: RegL_00.,RegL_01.
    EG_WZ_Kontakt_Garten: RegL_00.,RegL_01.
    Fernbedienung_8Tasten: RegL_00.
    Fernbedienung_8Tasten_Btn_01: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_02: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_03: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_04: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_05: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_06: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_07: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_8Tasten_Btn_08: RegL_01.,RegL_04.VCCU_Btn2
    Fernbedienung_Alarm: RegL_00.
    Fernbedienung_Alarm_armAway: RegL_01.,RegL_04.VCCU_Btn1
    Fernbedienung_Alarm_armHome: RegL_01.,RegL_04.VCCU_Btn1
    Fernbedienung_Alarm_disarm: RegL_01.,RegL_04.VCCU_Btn1
    Fernbedienung_Alarm_light: RegL_01.,RegL_04.VCCU_Btn1
    Garagentor: RegL_00.,RegL_01.
    OG_AZ_Kontakt_Seite: RegL_00.,RegL_01.
    OG_SZ_Kontakt_Balkon: RegL_00.,RegL_01.
    OG_SZ_Kontakt_Seite: RegL_00.,RegL_01.
    Signalgeber: RegL_00.
    Statusdisplay_OG: RegL_00.
    Statusdisplay_OG_Btn_01: RegL_01.
    Statusdisplay_OG_Btn_02: RegL_01.
    Statusdisplay_OG_Dis: RegL_01.
    Statusdisplay_OG_Key_01: RegL_01.
    Statusdisplay_OG_Key_02: RegL_01.
    Statusdisplay_OG_Key_03: RegL_01.
    Statusdisplay_OG_Key_04: RegL_01.
    Statusdisplay_OG_Key_05: RegL_01.
    Temperaturfuehler: .RegL_00.
    Temperaturfuehler_Climate: .RegL_01.,.RegL_07.,.RegL_08.,.RegL_09.
    Temperaturfuehler_SwitchTr: .RegL_01.
    Temperaturfuehler_Weather: .RegL_01.
    Temperaturfuehler_WindowRec: .RegL_01.
    Temperaturfuehler_remote: .RegL_01.

PairedTo missing/unknown
    Bewegungsmelder_Flur_EG
    EG_AR_Kontakt
    EG_HW_Kontakt_Seite
    EG_HW_Kontakt_vorneR
    EG_Haustuer_Kontakt
    EG_KU_Kontakt
    EG_Rauchmelder_Flur
    EG_WC_Kontakt
    EG_WZ_Kontakt_Garten
    Fernbedienung_8Tasten
    Fernbedienung_Alarm
    Garagentor
    OG_AZ_Kontakt_Seite
    OG_SZ_Kontakt_Balkon
    OG_SZ_Kontakt_Seite
    Signalgeber
    Statusdisplay_OG
    Temperaturfuehler

templist mismatch
    Temperaturfuehler_Climate: failed Entries:
     Temperaturfuehler_Climate :R_P1_0_tempListSat mismatch 07:30 21.5 24:00 22.5 ne empty ##
     Temperaturfuehler_Climate :R_P1_1_tempListSun mismatch 07:30 21.5 23:00 22.5 24:00 21.5 ne empty ##
     Temperaturfuehler_Climate :R_P1_2_tempListMon mismatch 06:00 21.5 09:00 21.5 17:00 21.5 23:00 22.5 24:00 21.5 ne empty ##
     Temperaturfuehler_Climate :R_P1_3_tempListTue mismatch 06:00 21.5 09:00 21.5 17:00 21.5 23:00 22.5 24:00 21.5 ne empty ##
     Temperaturfuehler_Climate :R_P1_4_tempListWed mismatch 06:00 21.5 09:00 21.5 17:00 21.5 23:00 22.5 24:00 21.5 ne empty ##
     Temperaturfuehler_Climate :R_P1_5_tempListThu mismatch 06:00 21.5 09:00 21.5 17:00 21.5 23:00 22.5 24:00 21.5 ne empty ##
     Temperaturfuehler_Climate :R_P1_6_tempListFri mismatch 06:00 21.5 09:00 21.5 15:00 21.5 23:00 22.5 24:00 21.5 ne empty ##
     Temperaturfuehler_Climate :R_P2_0_tempListSat mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P2_1_tempListSun mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P2_2_tempListMon mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P2_3_tempListTue mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P2_4_tempListWed mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P2_5_tempListThu mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P2_6_tempListFri mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_0_tempListSat mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_1_tempListSun mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_2_tempListMon mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_3_tempListTue mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_4_tempListWed mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_5_tempListThu mismatch 24:00 17.0 ne empty ##
     Temperaturfuehler_Climate :R_P3_6_tempListFri mismatch 24:00 17.0 ne empty ##


Gibt es hier eine Möglichkeit alles noch zu retten oder muss ich bei allen Geräten nochmal ein Pairing durchführen?

Danke und VG
Achim

Pfriemler

Das pairing kann eigentlich nicht kaputt sein. Die Defiitionen aus dem Backup ggf. zu retten ist das eine, aber die Daten der Devices (normalerweise über einen Neustart im statefile gerettet und hier wohl weg) müssten sich durch getConfigs wiederherstellen lassen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Thorsten Pferdekaemper

Zitat von: Pfriemler am 21 November 2017, 19:21:08Ich habe nur die (offenbar ketzerische) Frage gestellt, warum man die bei einem Device auswählbaren Attribute (konkret: in der Dropdownliste) nicht auch bei der in der Weboberfläche kurz darunter erhältlichen "Device specific help" erklärt bekommt
Die "Device specific help" (oder auch der Abschnitt zum Gerät in der Commandref) wird vom Modulautor direkt in der Moduldatei (also in seinem Quellcode) erfasst. Wenn jetzt jemand anderes zu diesem Modul (oder auch nur zu einer Instanz) im Rahmen eines anderen Moduls oder Befehls ein neues Attribut hinzufügt, dann weiß der Modulautor davon unter Umständen gar nichts. Natürlich könnten die beiden auch miteinander reden, aber das ist halt wieder mehr Aufwand. Außerdem kann es dann auch wieder sein, dass die Existenz dieses Attributs von der Verwendung des zweiten Moduls abhängt. Dann wird das Erwähnen dieses Attributs nur zu mehr Verwirrung beitragen.
Das alles könnte man auch wieder hinbiegen, aber dafür müsste man die Struktur der Commandref ändern.
Gruß,
   Thorsten 
FUIP

achim-e

Zitat von: Pfriemler am 22 November 2017, 10:54:19
Das pairing kann eigentlich nicht kaputt sein. Die Defiitionen aus dem Backup ggf. zu retten ist das eine, aber die Daten der Devices (normalerweise über einen Neustart im statefile gerettet und hier wohl weg) müssten sich durch getConfigs wiederherstellen lassen.
Vielen Dank -- das war's. Mit getConfig (bei manchen Devices sogar 2x) hat FHEM jetzt wieder alles sauber.

Pfriemler

Zitat von: Thorsten Pferdekaemper am 22 November 2017, 15:08:15
Die "Device specific help" ... wird vom Modulautor direkt in der Moduldatei ...
ist mir bekannt, ich habe schon öfter Moduldateien angesehen.

Zitatwird das Erwähnen dieses Attributs nur zu mehr Verwirrung beitragen.

Der Satz "Die Attribute A, B, C und D gehören zum Befehl E und werden dort erklärt" würde ja schon reichen. Das verwirrt nicht, führt nicht in die Irre, stellt keine redundanten Informationen bereit und ist bis auf den Umstand, dass es vielleicht mal mehr erwähnenswerte Attribute gibt, wartungsfrei.

Und zuguterletzt (und dann höre ich wirklich auf): man möge mal sehen, an welcher Stelle die Attribute für backup und restore erklärt und erwähnt sind, im Vergleich zu update.

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

marvin78

Wow. Man kann ein Thema tatsächlich sinnlos immer weiter treiben.

Patches einreichen ist übrigens nicht verboten, wenn einem Dinge nicht gefallen.

Mein Rat war schon immer: commandref als ganzes öffnen und Browsersuche verwenden. Effizient und schnell.

Dersch

#58
Bei mir ist 10_CUL_HM auch nach dem letzten Update nicht mehr zu gebrauchen.

https://paste.linuxlounge.net/#/l5bW9RGql1SewqH4N4TsYxsc2aI!HvAuP-7-0P1LNqL4iGEid6fjhzS19ymeZU3_HcYz0xo

Ist abzusehen ob der BUG behoben wird?

zap

Zitat von: raiderxxl am 20 November 2017, 13:27:30
Na Toll, jetzt steh ich ganz schön dumm da, denn ich habe keine Ahnung was das zu bedeuten hat...

Bin Kein Programmierer ... nur Dummer User (in diesem Fall)

Grüßle

Pascal

Du hast sicher gewusst worauf du dich einlässt, als du dich für eine opensource Lösung für dein Smarthome entschieden hast. Oder hast du einen Supportvertrag mit dem Entwickler  :o
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Hauswart

Nur zur Info betateilchen hat vor ein paar Posts den Workaround schon gepostet. Updaten auf die aktuellste Version, ein Wort im Quellcode löschen ("defined " in Zeile 7835) und FHEM neustarten und alles läuft problemlos. :)


Oder die Datei aus dem Anhang einspielen.
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Thorsten Pferdekaemper

Hi,
da Martin anscheinend anderweitig beschäftigt ist: Könnte sich vielleicht jemand von den SVN-Profis erbarmen, eine korrigierte Version (betateilchen-Patch) hochzuladen?
Ich persönlich habe zwar auch die Berechtigung (glaube ich), aber ich habe noch nie wirklich was mit SVN gemacht und würde nur ungern mit so einem weit verbreiteten Modul "üben".
Ich weiß auch, dass das nicht üblich ist und nur der Modulautor so etwas machen sollte, aber in dem Fall könnte man doch mal eine Ausnahme machen, oder?
Gruß,
   Thorsten
FUIP

knopf_piano

Ich helf mir hiermit
attr global exclude_from_update 10_CUL_HM.pm
zotac nano mit proxmox und ganz viel zeug drauf

CoolTux

Zitat von: Thorsten Pferdekaemper am 23 November 2017, 09:53:49
Hi,
da Martin anscheinend anderweitig beschäftigt ist: Könnte sich vielleicht jemand von den SVN-Profis erbarmen, eine korrigierte Version (betateilchen-Patch) hochzuladen?
Ich persönlich habe zwar auch die Berechtigung (glaube ich), aber ich habe noch nie wirklich was mit SVN gemacht und würde nur ungern mit so einem weit verbreiteten Modul "üben".
Ich weiß auch, dass das nicht üblich ist und nur der Modulautor so etwas machen sollte, aber in dem Fall könnte man doch mal eine Ausnahme machen, oder?
Gruß,
   Thorsten

Das kann nur Markus als SVN Verantwortlicher entscheiden. Wenn hier ein ok kommt kann ich das gerne übernehmen, oder halt Udo.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

zap

Statt eine Korrektur einzuchecken ohne zu wissen, was sich der Autor bei seinem Code gedacht hat könnte man ja auch einfach die letzte funktionierende Version im SVN zurückholen
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

eisman

hi,

ich habe seit 3 Tagen ein Problem, bei mir läuft alles ohne etwas zu ändern(HM)

WILL auch Problem  :'(

kein Absturz, die Blödem HM schalten und walten. Irgendwas muss ich was verkehrt machen......

gruss
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

Frank_Huber

Zitat von: eisman am 23 November 2017, 12:38:19
ich habe seit 3 Tagen ein Problem, bei mir läuft alles ohne etwas zu ändern(HM)
WILL auch Problem  :'(
kein Absturz, die Blödem HM schalten und walten. Irgendwas muss ich was verkehrt machen......

-->

Zitat von: betateilchen am 21 November 2017, 15:33:02
Um nochmal auf den eigentlich Bug zurückzukommen... es handelt sich schlichtweg um ein versionsabhängiges perl-Verhalten.
In der perl Dokumentation steht:

Also gibt es gar keine andere Lösung, als die Prüfung per defined() in der genannten Modulzeile zu entfernen.

Und vermutlich tritt das Problem bei martin aufgrund einer älteren perl Version in seiner Entwicklungsumgebung gar nicht auf, sonst hätte er das Modul vermutlich so nicht eingecheckt. Und vermutlich hat er deshalb auch diesen Thread hier noch gar nicht entdeckt...

Tedious

Zitat von: eisman am 23 November 2017, 12:38:19
hi,

ich habe seit 3 Tagen ein Problem, bei mir läuft alles ohne etwas zu ändern(HM)

WILL auch Problem  :'(

kein Absturz, die Blödem HM schalten und walten. Irgendwas muss ich was verkehrt machen......

gruss

Du HAST schon ein Problem, und zwar kein kleines. Dein Rechner ist definitiv out-of-date und somit ein Sicherheitsrisiko (falls im Netz)....
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

raiderxxl

Martin hat wohl echt wichtigeres zu tun ...

Schade...

FHEM VM Ubuntu-Server auf Intel® NUC-Kit NUC6i5SYH ESXi 6.5
FHEM auf Raspberry2 OSMC Hyperion und TTS

Homematic,TradfriHub und Lampen,WIFILight,Fritzbox,FritzDECT,NanoCul433,IT Steckdosen,Diverse Nachbar-Sensoren,XiaomiZigbee,
ESP_Signalduino,ESPEasy,Amad,HarmonyHub,WLED,MQTT,Tasmota....

CoolTux

Ich finde es nun auch nicht so schlimm. Es gibt eine einfache Lösung die jeder angehen kann. So schwer ist es doch nun auch nicht ein Wort zu entfernen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

pr3mi3r3

Trotzdem muss das im SVN gefixt werden, ich glaube nicht dass jeder FHEM User mit Homeatic Hardware hier in diesem Beitrag unterwegs ist!

wora

Hallo, ich bin neu hier im Forum und wahrscheinlich steht mir die Aussage nicht zu ?

Aber das dieses kleine Problem nicht gefixt wird finde ich schon bedenklich ? Bei mir funktioniert der Heizungsthermostat nicht mehr und das im Herbst/Winter ?

Klar kann ich diese kleine Änderung in den .pm File selber machen. Aber das kann nicht die Lösung für lange Zeit sein ?

Kann nicht jemand anders ausser dem Martin diese kleine Änderung einchecken ? Das darf doch nicht an einer einzigen Person hängen ?

Gruß
Wolfram

Beta-User

@wora und pr3mi3r3

Willkommen im Forum.

Ihr habt es mit freier Software zu tun, von daher ist diese Art Erwartungshaltung und (sicher nicht böse gemeinter) Kritik am aktuellen Zustand und den beteiligten Personen und Mechanismen schlicht nicht angebracht!

Alle, von denen ihr profitiert, bringen sich freiwillig hier ein, und insbesondere Martin zeichnet sich durch besonders langjährige und qualitativ hochwertige Arbeit aus, gepaart mit in der Regel schnellen Reaktionen auf Probleme. Er darf erwarten, dass ihm niemand ungefragt irgendwas am code ändert, und seien es noch so (vermeintlich?) einfache (?!?!) Dinge. Zwar dürfte jeder hier im Forum betateilchen ohne weiteres zutrauen, das richtige Schräubchen getroffen zu haben, aber es gehört sich einfach nicht.

Abhilfemaßnahmen sind bekannt und klar benannt, und ihr habt schließlich auch hierher gefunden.

Also: nicht beschweren, sondern diesen Anlaß nutzen, um über Themen wie Testsystem, Backupstrategie - und Mechanismen nachdenken - und bei Bedarf implementieren. FHEM ist m.E. ein gutes Angebot zur Hilfe zur Selbsthilfe, aber: Viel Macht bringt viel Verantwortung...

Just my2ct.

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Warum geht bei dir die Heizung ohne fhem nicht!?

Da ist aber (zusätzlich) was am Design falsch...

Bei mir (auch Homematic) läuft die Heizung autark mit eingestellten Wochenprogrammen...

Mit fhem mach ich nur (eher selten) Umschaltung von Wochenprogrammen und eben mitloggen um zu sehen was Sache ist...

Ja, der Fehler ist nicht schön aber es ist halt keine Bezahle-SW wo ein riesen Testaparat dahinter steht...
...und selbst wenn, dann wäre die SW halt nur für ein paar wenige Systeme freigegeben...

Und wenn man so schaut, es laufen schon teilweise sehr exotische Installationen, die kann ja gar keiner testen...

Aber ja: wäre schon gut, wenn (nach einigen Tagen nach bekannt werden) der Fehler im Update raus wäre...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Tedious

Nu, ich kann da beide Seiten verstehen.

A) Die Maintainer machen einen guten Job, sie machen das aber freiwillig und in ihrer Freizeit. Man muss ihnen zugestehen dass sie auch ein RL haben. Zudem bewegen wir uns hier im OpenSource-Bereich. Da muss jedem klar sein auf was er sich einlässt. Hier ist mal ein Fehler passiert, klar. Das passiert aber bei etablierten Bezahldiensten auch, man denke nur an die ständigen Ausfälle der Magenta-Cloud die ganze Smarthome-Systeme lahmlegen. Nevertheless, wer FHEM nutzt sollte zumindest rudimentäre Kenntnisse der Linux-Shell haben, denn sind solche Bugs schnell selbst gefixt. Ich habe nach dem Ausfall die einzelne Datei aus dem Backup zurückgespielt und das System läuft wieder. Zeitaufwand 2 Minuten.

B) Nicht jeder User ist ein Crack. Man stößt auf FHEM, probiert - hey, geht ja super - und baut nach und nach aus. Nicht jeder versteht die komplexen Zusammenhänge im System, aber erste Erfolgserlebnisse sind da. Klasse. Denn kommt ein Bug und man hängt da wie Jesus an Karfreitag. Blöd. Da man sich über die Zusammenhänge keine Gedanken gemacht hat funktioniert die Heizung nicht. Doppelt blöd im November. Man hofft auf Hilfe, hat aber keine Ahnung wie man im Dateisystem kopiert und Nano ist kein Freund. Großer Mist, denn man ist hilflos. Nach ein paar Tagen geht das immer noch nicht, man wird ärgerlich weil Frau und Kinder meckern (was man hat merkt man meistens erst wenn es nicht mehr da ist... alles Andere ist bezüglich des WAF ja selbstverständlich...)


Wie gesagt, ich verstehe beide Seiten. Definitiv. Insofern - von beiden Seiten ein bisschen mehr Toleranz und Verständnis für die Probleme des anderen, denn kann das hier wieder harmonisch werden ;)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Hauswart

Nur zur Info ich habe eine gepatchte Version hier im Thread hochgeladen. Einfach herunterladen, hochladen und bis zum offiziellen Fix warten.
https://forum.fhem.de/index.php/topic,79858.msg720176.html#msg720176
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

CoolTux

Ich habe das mal zum Thema bei den Developern gemacht. Hier die Aussage von Rudi dazu.
Ich finde das voll ok.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Zitat von: Tedious am 24 November 2017, 10:07:35
B) Nicht jeder User ist ein Crack. Man stößt auf FHEM, probiert - hey, geht ja super - und baut nach und nach aus. Nicht jeder versteht die komplexen Zusammenhänge im System, aber erste Erfolgserlebnisse sind da. Klasse. Denn kommt ein Bug und man hängt da wie Jesus an Karfreitag. Blöd.

Korrekt, ABER:
Manche Leute lernen (leider) nur durch solche Erfahrungen, welche Macht sie tatsächlich haben.
Als jemand, der NICHT Entwickler ist, sondern auch schlichter User darf ich sagen, dass ich zwar volles Verständnis für gepeinigte User habe, die erstmals in eine solche Falle laufen, aber keine Veranlassung seitens der Entwickler sehe, an diesem Zustand irgendetwas zu ändern.

Im Gegenteil: Je eher einem unbedarften Anfänger klargemacht wird, wie viel Verantwortung er hat (und wieviel ggf. auch schiefgehen kann), desto besser!

Der einzige Punkt, der m.E. ggf. zu bemängeln ist, ist der, dass vor dem Einstieg eben nicht der Hinweis kommt, der uns von der erstmaligen Anmeldung mit sudo bekannt ist: Achtung, du hast große Macht, du solltest verantwortlich damit umgehen...
Dsa wäre ein Punkt für's Wiki, der (lange nicht mehr nachgesehen) ggf. dort noch ergänzt werden kann (@Tedious: feel free, genug Erfahrung mit FHEM hast du ja!)

Wie gewohnt: just my2ct.

Beta-User

EDIT: Für Leute, denen nano nicht gefällt: mcedit nehmen, enthalten im Paket mc ;)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

marvin78

Das wird ja immer doller hier. Es werden eigene Design Fehler genutzt um auf Entwickler einzuhauen, die für FHEM in ihrer Freizeit programmieren. Die Lösung ist da, das ist aber noch kein Grund, die Kritik einfach stecken zu lassen. Das ganze hier bestätigt meine Meinung, dass FHEM einfach nur für einen begrenzten Nutzerkreis gedacht ist. Und das ist, wie ich finde, gut so. Wenn man die "komplexen Zusammenhänge" nicht versteht (oft ist es eher ein wollen, als ein können), dann lässt man die Finger davon.

Sorry, wer im kalten sitzt, weil ein kleiner BUG in CUL_HM vorhanden ist, ist selbst schuld und das gleich doppelt.

betateilchen

Im Entwicklerbereich wurde heute ein Lösungsweg für das hier beschriebene Problem beschlossen. Es wird im Laufe des Tages eine korrigierte Modulversion eingecheckt, die morgen per update verteilt wird.

Und dann hoffe, ich, dass irgendjemand diesen Thread hier schließt, um die sinnlosen Diskussionen abseits des Bugs zu beenden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

ZUR LÖSUNG DER URSPRÜNGLICHEN MELDUNG (BUG 10_CUL_HM.pm):

Die Version im svn ist in Kürze aktualisiert (Danke @Betateilechen), Martin wird übernehmen.
Die korrigierte Version wird ab morgen Vormittag über das automatische Update zur Verfügung gestellt.

Ich schließe den Thread damit weil die Meldung beseitigt ist. Danke @all