[gefixed] Heutiges CUL_HM update defekt

marvin78 · 07 Januar 2019, 11:29:18

Zitat von: det. am 07 Januar 2019, 11:14:55
irgendwie wird die Liste unter allr global exclude_from_update immer länger... Dabei findet jeder Entwickler mit Sicherheit 3-4 User mit unterschiedlichen Settings, welche gern bereit sind, die Module vor der Veröffentlichung auf Nebenwirkugen zu testen. Gibt es hier inzwischen Neuigkeiten, die ich überlesen habe?
attr HM_Name modelForce GeräteBezeichnung half leider bei meinem virtuellen doorcontakt nicht weiter

Und du glaubst, bei 3-4 Usern wird tatsächlich jedes Problem gefunden? Du bist auf dem Holzweg. Man muss wissen, auf was man sich einlässt, wenn man eine Software, wie FHEM einsetzt. Wenn man sich dementsprechend verhält, ist die Wahrscheinlichkeit, dass man in solche Fallen tappt sehr gering.

Natürlich kann man vom Entwickler Sorgfalt erwarten, aber nichts unmenschliches. Als User hingegen hat man alle Möglichkeiten, solche Probleme zu vermeiden. Das geht zwar nicht immer, dafür aber sehr einfach.

frank · 07 Januar 2019, 12:09:50

warum macht ihr überhaupt ein update, wenn es scheinbar so schlimm ist. ohne update braucht es auch kein exclude_from_update.

und wenn man nur einen bestimmten fix benötigt, kann man auch ein modul exclusiv updaten, ohne den rest zu gefährden.

ein update in fhem ist zwar kostenlos, aber nicht umsonst.

Udomatic · 07 Januar 2019, 12:17:46

Zitat von: marvin78 am 07 Januar 2019, 11:29:18
Wenn man sich dementsprechend verhält, ist die Wahrscheinlichkeit, dass man in solche Fallen tappt sehr gering.

Als neuer in diesem Forum möchte ich gerne Fragen, was das genau meint?

Ich bin z.B. in das Problem gelaufen, weil ich etwas neues in FHEM installiert habe. In jedem Wiki Artikel steht man soll vorher ein Update von FHEM durchführen, um auch immer aktuell zu sein. Gesagt, getan...

So schnell war dann auch das Problem da.

Meine Frage ist nicht kritisch gemeint sondern durchaus mit dem Versuch einen guten Prozess zu finden FHEM und all seine Module lauffähig aber doch aktuell zu halten.

Vielen Dank im Voraus.

link611 · 07 Januar 2019, 12:24:05

Zitat von: Hollo am 06 Januar 2019, 20:26:08
Ich frage einfach mal blöd nach dem aktuellen Stand, bevor noch mehr User Probleme haben und es dann wieder zig neue Threads gibt...

- Was ist die Ursache? (nur die Cul_HM?)
- Wird das fehlerhafte Modul weiterhin per Update verteilt?
- Was muss nach einem Restart gemacht werden?
- Was kann vor einem Restart gemacht werden?

Derzeitiger Kenntnisstand (bitte korrigieren):
- einfachster Weg ist das Einspielen der 10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg aus dem Restore-Ordner

Habe die 10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg wieder eingespielt, dann einen shutdown restart durchgeführt.
Scheint wieder alles zu funktionieren.

Pfriemler · 07 Januar 2019, 12:55:55

Tut mir jetzt ja ein bisschen leid für Euch alle, denn die Vorversion hatte ich im Test, leider ist das Verhalten bei mir auch erst heute morgen nach einem weiteren Neustart (Speicherkarte gewechselt) aufgetreten, den vorigen Neustart hatte meine Konfig noch recht unbeschadet überlebt, da hatte es nur einen Aktor "zerlegt". Ich hatte aber nicht damit gerechnet, dass das jetzt ins SVN geht...

@Martin: Die Rekonstruktion der models aus dem .mId scheint fehlerhaft. Entgegen Deinen Ausführungen zu modelForce setzen und löschen hatte es dieses Attribut dann heute doch in alle meine HM-Geräte geschafft (nicht nur die bei denen modelForce gesetzt wurde). Und dann schlug die Rekonstruktion fehl, Beispiel:

Code Auswählen

define HM_266A77 CUL_HM 266A7
attr HM_266A77 .devInfo 110100
attr HM_266A77 .mId 0068
attr HM_266A77 .stc 20
...
attr HM_266A77 model HASH(0x57aa460)
...
attr HM_266A77 subType

Danach gingen so ziemlich alle Geräte auf "virtual" und alle Kanäle der Geräte wurden gelöscht.

Ich habe mir inzwischen angewöhnt, vor einem Update hier ins Unterforum zu schauen, ob es gerade ein mglw. problematisches Update gab. Irgendeine arme Sau ist dann leider immer das Versuchskaninchen...

Nachtrag: modelForce ist eine neue Funktion. Ich würde bis zur endgültigen Klärung diese Funktion nicht verwenden.

marvin78 · 07 Januar 2019, 13:07:40

Zitat von: Udomatic am 07 Januar 2019, 12:17:46
Als neuer in diesem Forum möchte ich gerne Fragen, was das genau meint?

Testsystem, vor dem Update ins Forum schauen, nur das updaten, was man benötigt.

Es handelt sich hier nicht um ein Consumerprodukt. Ich sage es immer wieder gerne: FHEM ist nichts für Leute, die sich nicht voll darauf einlassen. Das heißt für mich auch, dass man immer und überall weiß, was man tut. Und das geht nun einmal darüber hinaus, nur Anleitungen zu lesen. Man muss das Vorgehen verstehen und dann weiß man auch, was man zu tun hat, um ähnliche Dinge zu vermeiden. Zur Not weiß man eben, wie ein restore funktioniert und man ist sicher. Wer das nicht kann, lasse bitte die Finger von FHEM oder lebe damit, dass man was nicht so einfach ist. Auf den Entwickler einhauen, ist immer falsch.

webdandy · 07 Januar 2019, 16:33:51

Mich hatte es leider auch erwischt, noch bevor ich diesen Beitrag hier gefunden habe.

10_CUL_HM.pm + 00_HMLAN.pm + fhem.cfg eingespielt + shutdown restart und alles läuft erstmal wieder.

Pfriemler · 07 Januar 2019, 16:50:27

Zitat von: det. am 07 Januar 2019, 11:14:55
irgendwie wird die Liste unter allr global exclude_from_update immer länger...

Gibt es noch mehr solche Pannen in FHEM? $:-\$
10_CUL_HM.pm kommt jetzt erst mal sicherheitshalber auf die Liste. Ist zwar unschön, aber wie schon treffend gesagt: Vorwürfe sind unangebracht.

det. · 07 Januar 2019, 19:25:12

Zitat von: Pfriemler am 07 Januar 2019, 16:50:27
Gibt es noch mehr solche Pannen in FHEM? $:-\$
10_CUL_HM.pm kommt jetzt erst mal sicherheitshalber auf die Liste. Ist zwar unschön, aber wie schon treffend gesagt: Vorwürfe sind unangebracht.

Zur Frage, ja Pannen würde ich das nicht unbedingt nennen, sind zum Teil auch Module mit selbst gefixten Sachen, die sonst beim nächsten Update wieder weg sind und ne Liste kann ich Dir höchstens per pm zukommen lassen wegen:
angeblicher Vorwürfe - ich hatte das als gutgemeinten Hinweis gedacht, aber von Hero Member mit 3jahre späterem Fhem Einstieg, aber 5-7 mal mehr Postings in der kürzeren Zeit muss ich mich nicht schulmeistern lassen.

Christoph Morrison · 07 Januar 2019, 19:31:52

Zitat von: Pfriemler am 07 Januar 2019, 16:50:27
Gibt es noch mehr solche Pannen in FHEM? $:-\$
10_CUL_HM.pm kommt jetzt erst mal sicherheitshalber auf die Liste. Ist zwar unschön, aber wie schon treffend gesagt: Vorwürfe sind unangebracht.

Naja das ist immer so, wenn man Software aktualisiert (und das soll keine Entschuldigung sein). Selbst Microsoft muss Updates gelegentlich (und in letzter Zeit häufiger) zurückziehen, weil etwas nicht funktioniert hat (und die Dinge bei Leuten gelöscht wurden etc.). War ja auch nicht das erste mal bei CUL_HM - aber ich benutze hier geschenkte Software und habe halt keinen Anspruch darauf, dass sie absolut fehlerfrei ist.

Deswegen: Testsystem und dann halt individuell testen / eine eigene QA dahinter bauen. Ich gucke mir z.B. die Commits für die Module, die ich benutze, in Normalfall mal vorher an bevor ich das System aktualisiere, auch weil ich ein paar Patches habe, die ich nach einem Update einspiele.

marvin78 · 07 Januar 2019, 19:35:28

Zitat von: det. am 07 Januar 2019, 19:25:12
Zur Frage, ja Pannen würde ich das nicht unbedingt nennen, sind zum Teil auch Module mit selbst gefixten Sachen, die sonst beim nächsten Update wieder weg sind und ne Liste kann ich Dir höchstens per pm zukommen lassen wegen:
angeblicher Vorwürfe - ich hatte das als gutgemeinten Hinweis gedacht, aber von Hero Member mit 3jahre späterem Fhem Einstieg, aber 5-7 mal mehr Postings in der kürzeren Zeit muss ich mich nicht schulmeistern lassen.

denk einfach nochmal nach. Bin raus.

ext23 · 07 Januar 2019, 20:20:23

Kann mir mal bitte jemand sagen welche Version das genau betrifft? Ich hatte gestern ein Update gemacht aber noch sieht alles gut aus. Ich habe nur Probleme mit einem virtual_1 device wo ich die Temp nicht mehr setzen kann, warum auch immer. Kann aber auch ein anderes Problem sein.

Ich habe derzeit:
# $Id: 10_CUL_HM.pm 18153 2019-01-05 23:21:58Z martinp876 $
# $Id: 00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876 $

/Daniel

LuckyDay · 07 Januar 2019, 20:32:09

https://forum.fhem.de/index.php/topic,93930.msg883035/topicseen.html#new

lesen bildet

wer traut sich zu testen , laden aus dem SVN?

Christoph Morrison · 07 Januar 2019, 20:35:50

Zitat von: ext23 am 07 Januar 2019, 20:20:23
Kann mir mal bitte jemand sagen welche Version das genau betrifft? Ich hatte gestern ein Update gemacht aber noch sieht alles gut aus. Ich habe nur Probleme mit einem virtual_1 device wo ich die Temp nicht mehr setzen kann, warum auch immer. Kann aber auch ein anderes Problem sein.

Ich habe derzeit:
# $Id: 10_CUL_HM.pm 18153 2019-01-05 23:21:58Z martinp876 $
# $Id: 00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876 $

/Daniel

Die hier müssten die letzten funktionierenden davor gewesen sein:
00_HMLAN.pm Rev. 18041
10_CUL_HM.pm Rev. 18113

ext23 · 07 Januar 2019, 21:08:41

Ahh misst ok dann spiele ich auch mal lieber die alten wieder ein, dann habe ich auch schon das faule Ei erwischt, egal.

Danke.

UPDATE: OK alten Module und die 20 config files mit einem compare tool manuell angepasst, das waren zum großen Teil diese ganzen mID Einträge in den ATTRs die ich entfernt habe. Ich hatte dummerweise gestern seit 3 Wochen mal wieder ein Update gemacht und ausgerechnet an dem Tag auch noch etliche Sachen geändert. Gut selber Schuld, passiert.

Läuft wieder.

/Daniel